Closed Bug 857115 Opened 10 years ago Closed 8 years ago

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


(Core :: WebRTC: Networking, defect, P3)






(Reporter: jsmith, Unassigned)


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


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


(1 file)

Attached file 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.
Whiteboard: [WebRTC][blocking-webrtc-]
Blocks: Talkilla
+1. This is necessary for our application of WebRTC as well, seen here: and explained (with relevance to this issue) here:
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.
See Also: → 1004510
Priority: -- → P1
Target Milestone: --- → mozilla33
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)
Depends on: 1017886
Depends on: 1017888
Priority: P1 → P3
Blocks: 1004510
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.
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
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.
Closed: 8 years ago
Resolution: --- → DUPLICATE
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.
You need to log in before you can comment on or make changes to this bug.