Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asymmetry between RTP and RTCP within the API #223

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

Asymmetry between RTP and RTCP within the API #223

aboba opened this issue Jun 30, 2015 · 2 comments

Comments

@aboba
Copy link
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
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

@aboba aboba added the PR exists label Jul 8, 2015
robin-raymond pushed a commit that referenced this issue Sep 8, 2015
#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
robin-raymond pushed a commit that referenced this issue Sep 21, 2015
… 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
@aboba aboba closed this as completed Oct 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant