Implement support for renegotiation and negotiationneeded events in the Peer Connection handshake

RESOLVED DUPLICATE of bug 1017888

Status

()

P3
normal
RESOLVED DUPLICATE of bug 1017888
6 years ago
3 years ago

People

(Reporter: jsmith, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Trunk
mozilla35
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [WebRTC][blocking-webrtc-])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 732339 [details]
Example Mochitest

Implement renegotiation and negotiationneeded event handling in the Peer Connection handshake. This means handling cases when we need to renegotiate the handshake between two peers for various reasons - including one such example seen in the attached mochitest where the remote peer gets a new SDP for the connected local peer.
(Reporter)

Updated

6 years ago
Duplicate of this bug: 856927
(Reporter)

Updated

6 years ago
Whiteboard: [WebRTC][blocking-webrtc-]

Updated

5 years ago
Duplicate of this bug: 870072
Blocks: 859886

Updated

5 years ago
Duplicate of this bug: 947706

Comment 4

5 years ago
+1. This is necessary for our application of WebRTC as well, seen here: http://bevry.github.io/interconnect/ and explained (with relevance to this issue) here: https://github.com/DamonOehlman/damonoehlman.github.io/issues/23

Comment 5

5 years ago
+1

Comment 6

5 years ago
This is *so* necessary for any type of video chats. Users won't trust the computer, if the camera LED won't go off if it's muted. It creates major trust issues.

Updated

4 years ago
See Also: → bug 1004510
Priority: -- → P1
Target Milestone: --- → mozilla33

Comment 7

4 years ago
shell break into multiple bugs

1. config and troubleshooting if we change conduits when active - currently blows part [investigation, p=2]

2. signalling part (once #1 done) that pulls the pins to stop flowing through path.  cleaning up code path and working with #1 changes (p=3)

Updated

4 years ago
Depends on: 1017886

Updated

4 years ago
Depends on: 1017888
Priority: P1 → P3

Comment 8

4 years ago
In our iOS app we are now implementing support for changing between the front-facing and rear-facing camera. This requires support for renegotiation. Alternatively we can start a new PeerConnection, but we would like to avoid doing this when it is only required by Firefox. I'm a therefore a bit concerned that the priority of this bug has been lowered to P3. It is realistic that this will be done in time for Firefox 33?
We're working instead on support for "Doohickies" (now called RTPSender and RTPReceiver) and a replaceTrack operation on RTPSender.  See bug 1032835 and bug 1032839.  This should allow camera changes without reinvite at all.

Comment 10

4 years ago
Camera substitutions is only one (narrow) use case for renegotiation.
Converting a one way PeerConnection with a renegotiation aware browser (Chrome) into a two way one is another example where renegotiation is needed. Right now you have to create a brand new PeerConnection and hand over or keep both open.
Target Milestone: mozilla33 → mozilla35
Keywords: dev-doc-needed

Comment 11

4 years ago
Hey guys, haven't seen activity on this and was hoping to get more attention to it. Maire put a milestone of mozilla35, so what's going on with this bug? :/
Work for this was done on bug 1017888, and it landed in Fx38.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1017888

Comment 13

4 years ago
Another use case that this will be useful: adding a second video stream (like a screen or window stream) without creating a second, parallel peer connection.

Updated

3 years ago
Duplicate of this bug: 881313
Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.