Payload Type #147

Closed
aboba opened this Issue Sep 1, 2014 · 4 comments

Projects

None yet

3 participants

@aboba
Contributor
aboba commented Sep 1, 2014

From Iñaki Baz Castillo [ibc@aliax.net]:

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

@aboba
Contributor
aboba commented Sep 3, 2014

This does not appear to be an API issue, as noted by Robin:
http://lists.w3.org/Archives/Public/public-ortc/2014Sep/0002.html

However, it might be worth clarifying getCapabilities() behavior as noted here:
http://lists.w3.org/Archives/Public/public-ortc/2014Sep/0001.html

@aboba
Contributor
aboba commented Sep 3, 2014

Potential clarification to Section 9.4.1 is to add the following text to the definition of preferredPayloadType:

preferredPayloadType of type payloadtype
The preferred RTP payload type for the codec denoted by RTCRtpCodecCapability.name. Where RTCRtpCapabilities.codecs.preferredPayloadtype is provided via calling RTCRtpSender.getCapabilities() it represents the preferred RTP payload type for sending; where it is returned via calling RTCRtpReceiver.getCapabilities() it represents the preferred RTP payload type for receiving. Overall, this attribute was added to make it possible for the sender and receiver to pick a matching payload type when creating sender and receiver parameters. To avoid potential payload type conflicts, the value of RTCRtpCodecCapability.preferredPayloadtype should be different for each value of RTCRtpCodecCapability.name.

@aboba
Contributor
aboba commented Sep 22, 2014

Proposed revision for clarity:

"The preferred RTP payload type for the codec denoted by RTCRtpCodecCapability.name. This attribute was added to make it possible for the sender and receiver to pick a matching payload type when creating sender and receiver parameters. When returned by RTCRtpSender.getCapabilities(), RTCRtpCapabilities.codecs.preferredPayloadtype represents the preferred RTP payload type for sending. When returned by RTCRtpReceiver.getCapabilities(), RTCRtpCapabilities.codecs.preferredPayloadtype represents the preferred RTP payload type for receiving. To avoid payload type conflicts, each value of RTCRtpCodecCapability.name should have a unique value of RTCRtpCodecCapability.preferredPayloadtype."

@ibc
Contributor
ibc commented Sep 24, 2014

👍

@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Oct 14, 2014
Robin Raymond Address questions about RTCDtlsTransport.start(), as noted in: Issue #…
…146

Address questions about RTCRtpCodecCapability.preferredPayloadType, as noted in: Issue #147
Address questions about RTCRtpSender.setTrack() error handling, as noted in: Issue #148
Partially address 'automatic' use of scalable video coding (in RTCRtpReceiver.receive()) as noted in: Issue #149
Renamed RTCIceListener to RTCIceGatherer as noted in: Issue #150
Added text on multiplexing of STUN, TURN, DTLS and RTP/RTCP, as noted in: Issue #151
Address issue with queueing of candidate events within the RTCIceGatherer, as noted in: Issue #152
Clarify behavior of RTCRtpReceiver.getCapabilities(kind), as noted in: Issue #153
7a48e0b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment