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

Status: RESOLVED DUPLICATE of bug 1017888

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

Description

[Jason Smith [:jsmith]]

Attachment: 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.

Comment 4

[Benjamin Lupton]

+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

[Ates Goral]

+1

Comment 6

[gk]

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.

Comment 7

[:shell escalante]

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)

Comment 8

[Thomas Bruun]

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?

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

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

[Mathieu Hofman]

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.

Comment 11

[Alfonso Martinez]

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? :/

Comment 12

[Maire Reavy [:mreavy]]

Work for this was done on bug 1017888, and it landed in Fx38.

Comment 13

[Xander Dumaine]

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.