Asymmetry between RTP and RTCP within the API #223

Closed
aboba opened this Issue Jun 30, 2015 · 2 comments

Projects

None yet

1 participant

@aboba
Contributor
aboba commented Jun 30, 2015

Currently the API draft does not state that RTP and RTCP IceGatherers need to have the same ufrag/password. Within SDP, this is a requirement since RTP/RTCP share the same m-line.

Also, we have iceTransport.createAssociatedTransport() for creation of an RTCP IceTransport and iceGatherer.createAssociatedGatherer() for creation of an RTCP IceGatherer. If createAssociatedGatherer() is called before createAssociatedTransport, then the RTCP IceTransport can be associated with the RTCP IceGatherer. Otherwise, the RTCP IceTransport and RTCP IceGatherer are not associated until rtcpIceTransport.start() is called. The association enables pruning of an RTCP IceGatherer. This leads me to wonder whether not calling .createAssociatedGatherer first should result in an error.

@aboba aboba added the 1.1 label Jun 30, 2015
@aboba
Contributor
aboba commented Jun 30, 2015

One aspect which is not currently specified is that .createAssociatedGatherer has to create an RTCP IceGatherer with the same usernameFragment/password as the RTP IceGatherer. From the JSEP draft:

Each m= section MUST include the following attribute lines:

o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245], Section 15.4.

Should it be required that RTP and RTCP IceGatherers share the same RTCIceParameters and RTCIceGatherOptions?

For example, we could add the following text to Section 2.3.2:

Create an associated RTCIceGatherer for RTCP, with the same RTCIceParameters and RTCIceGatherOptions as for the RTP RTCIceGatherer. If

@aboba aboba added the 1.0 label Jun 30, 2015
@aboba
Contributor
aboba commented Jul 8, 2015

Proposed fix is to add the following text to Section 2.3.2:
createAssociatedGatherer
Create an associated RTCIceGatherer for RTCP, with the same RTCIceParameters and RTCIceGatherOptions.

@robin-raymond robin-raymond pushed a commit that referenced this issue Sep 8, 2015
Robin Raymond - Added the "failed" state to RTCDtlsTransportState, as noted in:
#219

- Added support for WebRTC 1.0 RTCIceCredentialType, as noted in:
#222

- Clarified behavior of createAssociatedGatherer(), as noted in:
#223

- Fixed SCTP port numbers, as noted in:
#227
2e5238d
@robin-raymond robin-raymond pushed a commit that referenced this issue Sep 21, 2015
Robin Raymond Added support for the WebRTC 1.0 certificate management API, as noted…
… in: Issue #195

Added certificate argument to the RTCDtlsTransport constructor, as noted in: Issue #218
Added the "failed" state to RTCDtlsTransportState, as noted in: Issue #219
Changed getNominatedCandidatePair to getSelectedCandidatePair, as noted in: Issue #220
Added support for WebRTC 1.0 RTCIceCredentialType, as noted in: Issue #222
Clarified behavior of createAssociatedGatherer(), as noted in: Issue #223
Changed spelling from "iceservers" to "iceServers" for consistency with WebRTC 1.0, as noted in: Issue #225
Added support for SCTP port numbers, as noted in: Issue #227
Changed "outbound-rtp" to "outboundrtp" within the Statistics API, as noted in: Issue #229
Changed maxPacketLifetime and maxRetransmits from unsigned short to unsigned long, as noted in: Issue #231
Clarified DataChannel negotiation, as noted in: Issue #233
Added getContributingSources() method, as noted in: Issue #236
Fixes to Examples 5 and 6, as noted in: Issue 237 and Issue #239
Fixed cut and paste errors in Example 11, as noted in: Issue #241
674f156
@aboba aboba closed this Oct 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment