Single peer connection not working with basic example

[arsenicraghav]

Description The single peer connection change is not working as the basic example is unable to receive the remote stream.

Steps to reproduce the issue:

1. Take the latest master from Licode.

2. Enable peer connection in the licode_config by setting config.erizoController.allowSinglePC = true;

3. Use single peer connection in the basic example by setting

var singlePC = true; 
room.connect({singlePC: singlePC});

Describe the results you received: Only Local stream is displayed and no remote stream is returned

Server logs shows the following:

2018-03-26 19:01:49.757  - WARN: ErizoController - Room - message: Triggering removal of stream because of ErizoJS timeout, streamId: 267989200590152300
2018-03-26 19:01:49.757  - DEBUG: ErizoController - Room - message: sendMsgToRoom, clientId: f72a6276-386d-48e9-824d-d81b3f82b989 , roomId: 5ab8f5dd5bf86010e9125b50 ,  onRemoveStream
2018-03-26 19:01:49.757  - WARN: ErizoController - Room - message: Triggering removal of stream because of ErizoJS timeout, streamId: 267989200590152300
2018-03-26 19:01:49.757  - DEBUG: ErizoController - Room - message: sendMsgToRoom, clientId: f72a6276-386d-48e9-824d-d81b3f82b989 , roomId: 5ab8f5dd5bf86010e9125b50 ,  onRemoveStream

Browser Logs shows:

INFO:  Candidates to be added:  0 Array []

INFO:  Local candidates to send: 0

INFO:  Sending message Object { type: "candidate", candidate: {…} }

INFO:  Sending message Object { type: "candidate", candidate: {…} }

INFO:  Gathered all candidates. Sending END candidate

INFO:  Sending message Object { type: "candidate", candidate: {…} }

Describe the results you expected: Expected the basic example to work normally.

Licode commit/release where the issue is happening Latest master Additional environment details (Local, AWS, Docker, etc.): Local ubuntu 14.04 LTS

[streichman]

I know this is from a bit ago, and is technically a support request - but for the OP and for google - It seems one may have to set the 'config.erizoController.maxErizosUsedByRoom' to 1 in order to see a single PeerConnection.

Found the answer by asking here: https://discourse.lynckia.com/t/single-peerconnection-documentation/857/5

[miniruwan]

After setting the 'config.erizoController.maxErizosUsedByRoom' to 1, 2 peers can send/receive video without any issue.

But when a 3rd peer joins, I see the following error in 3rd peer's console. ERROR: message: DOMException: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote answer sdp: Media section has more than one track specified with a=ssrc lines which is not supported with Unified Plan. in baseStack at processAnswer

Note that I have enabled unified-plan in client as shown in the following diff

--- a/erizo_controller/erizoClient/src/webrtc-stacks/BaseStack.js
+++ b/erizo_controller/erizoClient/src/webrtc-stacks/BaseStack.js
@@ -21,7 +21,8 @@ const BaseStack = (specInput) => {
 
   that.pcConfig = {
     iceServers: [],
-    sdpSemantics: 'plan-b',  // WARN: Chrome 72+ will by default use unified-plan
+    sdpSemantics: 'unified-plan',
   };

Explanation

In the following explanation I have only focused about video because it is the same logic for audio

Following is the offer sent by 3rd peer:

a=msid-semantic: WMS FnhTJfo47SSwErbDvfe4uQlgkzYFmaSyfOXU a=group:BUNDLE 0 1 ... m=video 45270 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 ... a=setup:actpass a=mid:1 a=sendrecv a=ice-ufrag:KkO2 a=ice-pwd:yim0DsBKdDG/bEJlFYgrhcCm a=fingerprint:sha-256 19:E6:F4:BD:64:EA:8F:D0:08:3D:99:48:67:DF:62:6C:95:AA:BD:E9:FE:EF:0E:CF:82:19:CF:6F:54:AB:14:35 a=candidate:2311777672 1 udp 2122260223 192.168.1.30 45270 typ host generation 0 a=ice-options:trickle a=ssrc:991041235 cname:zRMgStZIr2yBwF1b a=ssrc:991041235 msid:FnhTJfo47SSwErbDvfe4uQlgkzYFmaSyfOXU de1b1133-cc96-44e7-850f-0d45f4d0bc1c a=ssrc:991041235 mslabel:FnhTJfo47SSwErbDvfe4uQlgkzYFmaSyfOXU a=ssrc:991041235 label:de1b1133-cc96-44e7-850f-0d45f4d0bc1c a=ssrc:361247311 cname:zRMgStZIr2yBwF1b a=ssrc:361247311 msid:FnhTJfo47SSwErbDvfe4uQlgkzYFmaSyfOXU de1b1133-cc96-44e7-850f-0d45f4d0bc1c a=ssrc:361247311 mslabel:FnhTJfo47SSwErbDvfe4uQlgkzYFmaSyfOXU a=ssrc:361247311 label:de1b1133-cc96-44e7-850f-0d45f4d0bc1c a=ssrc-group:FID 991041235 361247311 a=rtcp-mux

The above offer describes about peer3's sending stream labled FnhTJfo47SSwErbDvfe4uQlgkzYFmaSyfOXU

Following is the answer received from licode server

s=LicodeMCU t=0 0 a=msid-semantic: WMS * a=group:BUNDLE 0 1 ... m=video 9 UDP/TLS/RTP/SAVPF 96 ... a=setup:active a=mid:1 a=sendrecv a=ice-ufrag:xx0O a=ice-pwd:7eCLdwdTrWjv7A9VgnQGPp a=fingerprint:sha-256 AE:3B:50:15:6B:19:CC:EE:86:DD:7D:0D:74:7E:EE:89:BD:2C:39:33:46:4B:50:B0:A0:6F:EA:D8:96:D8:C7:F7 a=candidate:1 1 udp 2013266431 18.139.116.65 50198 typ host generation 0 a=candidate:2 1 udp 1677721855 18.139.116.65 50198 typ srflx generation 0 a=end-of-candidates a=ssrc:1901431248 cname:erizo a=ssrc:1901431248 msid:EknBpi1XcewMBXNatpjRGo2oXyzYgHvbEYbz EknBpi1XcewMBXNatpjRGo2oXyzYgHvbEYbz1 a=ssrc:1901431248 mslabel:EknBpi1XcewMBXNatpjRGo2oXyzYgHvbEYbz a=ssrc:1901431248 label:1 a=ssrc:1265563923 cname:erizo a=ssrc:1265563923 msid:nCzjsFePzOSqDFFT4I8mfyEdtXkGLi9OqQca nCzjsFePzOSqDFFT4I8mfyEdtXkGLi9OqQca1 a=ssrc:1265563923 mslabel:nCzjsFePzOSqDFFT4I8mfyEdtXkGLi9OqQca a=ssrc:1265563923 label:1 a=rtcp-mux

The problem is above answer having two streams (EknBpi1XcewMBXNatpjRGo2oXyzYgHvbEYbz and nCzjsFePzOSqDFFT4I8mfyEdtXkGLi9OqQca) in the same transceiver with mid:1

• The 3rd peer sends an offer to licode server which contains one video transceiver.
• But licode has to send two video tracks (video tracks of peer1 and peer2) in the answer.
• But the offer SDP has only one video transceiver. Answerer cannot add more video transceivers.
• The answer contains only one video transceiver. But has two msid's

Suggestion

I think better way of implementing SinglePC + Unified Plan is, licode server being able to be the offerer, so that licode server can add as many transceivers as needed.

[jcague]

Which version of Chrome are you using? we force Plan B to avoid this issue until we add support to Unified Plan.

[miniruwan]

@jcague Sorry forgot to mention that, I have enabled unified-plan in client as shown in the following diff

--- a/erizo_controller/erizoClient/src/webrtc-stacks/BaseStack.js
+++ b/erizo_controller/erizoClient/src/webrtc-stacks/BaseStack.js
@@ -21,7 +21,8 @@ const BaseStack = (specInput) => {
 
   that.pcConfig = {
     iceServers: [],
-    sdpSemantics: 'plan-b',  // WARN: Chrome 72+ will by default use unified-plan
+    sdpSemantics: 'unified-plan',
   };

[jcague]

ok, we don’t support unified plan yet so you need to set plan b again to make it work

[miniruwan]

Ok. I understand. May I know any timeline regarding unified-plan implementation?