Switch the WebRTC DTLS peer from active to passive.

modules/xmpp/JingleSessionPC.js

@@ -340,31 +340,13 @@ JingleSessionPC.prototype.sendAnswer = function (success, failure) {
 JingleSessionPC.prototype.createdAnswer = function (sdp, success, failure) {
     //logger.log('createAnswer callback');
 
-    // XXX Videobridge is the (SDP) offerer and WebRTC (e.g. Chrome) is the
-    // answerer (as orchestrated by Jicofo). In accord with
-    // http://tools.ietf.org/html/rfc5245#section-5.2 and because both peers
-    // are ICE FULL agents, Videobridge will take on the controlling role and
-    // WebRTC will take on the controlled role. In accord with
-    // https://tools.ietf.org/html/rfc5763#section-5, Videobridge will use the
-    // setup attribute value of setup:actpass and WebRTC will be allowed to
-    // choose either the setup attribute value of setup:active or
-    // setup:passive. Chrome will by default choose setup:active because it is
-    // RECOMMENDED by the respective RFC since setup:passive adds additional
-    // latency. The case of setup:active allows WebRTC to send a DTLS
-    // ClientHello as soon as an ICE connectivity check of its succeeds.
-    // Unfortunately, Videobridge will be unable to respond immediately because
-    // may not have WebRTC's answer or may have not completed the ICE
-    // connectivity establishment. Even more unfortunate is that in the
-    // described scenario Chrome's DTLS implementation will insist on
-    // retransmitting its ClientHello after a second (the time is in accord
-    // with the respective RFC) and will thus cause the whole connection
-    // establishment to exceed at least 1 second. To work around Chrome's
-    // idiosyncracy, don't allow it to send a ClientHello i.e. change its
-    // default choice of setup:active to setup:passive.
-    sdp.sdp = sdp.sdp.replace(/a=setup:active/g, 'a=setup:passive');
-
     var self = this;
     this.localSDP = new SDP(sdp.sdp);
+
+    this._fixAnswerRFC4145Setup(
+            /* offer */ this.remoteSDP,
+            /* answer */ this.localSDP);
+
     var sendJingle = function (ssrcs) {
         var accept
             = $iq({ to: self.peerjid, type: 'set' })
@@ -417,6 +399,55 @@ JingleSessionPC.prototype.createdAnswer = function (sdp, success, failure) {
     }
 };
 
+/**
+ * Modifies the values of the setup attributes (defined by
+ * {@link http://tools.ietf.org/html/rfc4145#section-4}) of a specific SDP
+ * answer in order to overcome a delay of 1 second in the connection
+ * establishment between Chrome and Videobridge.
+ *
+ * @param {SDP} offer - the SDP offer to which the specified SDP answer is
+ * being prepared to respond
+ * @param {SDP} answer - the SDP to modify
+ * @private
+ */
+JingleSessionPC.prototype._fixAnswerRFC4145Setup = function (offer, answer) {
+    // XXX Videobridge is the (SDP) offerer and WebRTC (e.g. Chrome) is the
+    // answerer (as orchestrated by Jicofo). In accord with
+    // http://tools.ietf.org/html/rfc5245#section-5.2 and because both peers
+    // are ICE FULL agents, Videobridge will take on the controlling role and
+    // WebRTC will take on the controlled role. In accord with
+    // https://tools.ietf.org/html/rfc5763#section-5, Videobridge will use the
+    // setup attribute value of setup:actpass and WebRTC will be allowed to
+    // choose either the setup attribute value of setup:active or
+    // setup:passive. Chrome will by default choose setup:active because it is
+    // RECOMMENDED by the respective RFC since setup:passive adds additional
+    // latency. The case of setup:active allows WebRTC to send a DTLS
+    // ClientHello as soon as an ICE connectivity check of its succeeds.
+    // Unfortunately, Videobridge will be unable to respond immediately because
+    // may not have WebRTC's answer or may have not completed the ICE
+    // connectivity establishment. Even more unfortunate is that in the
+    // described scenario Chrome's DTLS implementation will insist on
+    // retransmitting its ClientHello after a second (the time is in accord
+    // with the respective RFC) and will thus cause the whole connection
+    // establishment to exceed at least 1 second. To work around Chrome's
+    // idiosyncracy, don't allow it to send a ClientHello i.e. change its
+    // default choice of setup:active to setup:passive.
+    if (offer && answer
+            && offer.media && answer.media
+            && offer.media.length == answer.media.length) {
+        answer.media.forEach(function (a, i) {
+            if (SDPUtil.find_line(
+                    offer.media[i],
+                    'a=setup:actpass',
+                    offer.session)) {
+                answer.media[i]
+                    = a.replace(/a=setup:active/g, 'a=setup:passive');
+            }
+        });
+        answer.raw = answer.session + answer.media.join('');
+    }
+}
+
 JingleSessionPC.prototype.terminate = function (reason,  text,
                                                 success, failure) {
     var term = $iq({to: this.peerjid,