n-s-s can't seem to connect to Janus MCU.

[dzatoah]

If I try to make a call in my test setup my logs get spammed with this message:

No MCU publisher found for session <SESSION_ID> to send &{Type:candidate Sid:1655727733735 RoomType:video Bitrate:0 Payload:map[candidate:map[candidate:candidate:14 1 UDP 92216831 <SERVER_IPV4_ADDRESS> 55127 typ relay raddr <SERVER_IPV4_ADDRESS> rport 55127 sdpMLineIndex:2 sdpMid:2]]} to <SESSION_ID>

I'm using the following version on debian unstable: nextcloud-spreed-signaling 0.4.1-2 janus 1.0.1-1+b1

/etc/nextcloud-spreed-signaling/server.conf:

[mcu]
type = janus
url = ws://127.0.0.1:8188

/etc/janus/janus.transport.websockets.jcfg:

general: {
        json = "indented"
        ws = true
        ws_port = 8188
        wss = false
        ws_logging = "err,warn,notice,info,all"
}

[fancycode]

Janux 1.x is currently untested / unsupported. Please use a 0.x version for now.

[dzatoah]

Mhh, I've compiled the 0.x branch by myself and the problem persists.

[dzatoah]

signaling.log

nextcloud-spreed-signaling logs while starting a call.

[fancycode]

nextcloud-spreed-signaling logs while starting a call.

Here is the actual problem: Jun 20 13:50:21 nextcloud-hpb-setpu nextcloud-spreed-signaling-server[186551]: hub.go:1739: Session WGtc1CQKlfKkqg2cMvLrD-uiAeCSuV2M_yNFMdcAhXx8PT1BWnRpY1IzVVRyUDMtOGZ6R0ZRVmhlUndfNGJrWUlyNGl6b01fZFdBdWZ2N1Q2TmVBM2RDUXB4VW5FaFYteDBubnRCdU5paDljdFlMR21JdDROQWZRcUtOeFI3VlFSUUJickxOcC1MQ25CenN3aEVaR3hHS2dMYWJ6UjZJNU9qbFhmYkI0Wm5jS2VsRkRpMFNQUFNDcmgxUElud2ZHSFJBZFpUc1VGUzV5REs5UE9HdmxqdWx0R0M1T1F8NzEwMzM3NTU2MQ== sent unsupported offer video, ignoring (payload does not contain a valid sdp)

From the logs it looks like this is Firefox 100 on Linux, is this correct? I'm not aware of generic issues with this OS/Browser, do you have any extensions installed that might alter WebRTC data? Could you check the network tab for the actual data sent through the WebSocket connection to the signaling server?

[dzatoah]

All my extensions shouldn't affect WebRTC at all. I don't think this is the issue since I've tested it with chromium too. Logfile while starting a call in chromium.

signaling2.log

Janus Log:

Creating new session: 7032162788712199; 0x7f2400005f50
Creating new handle in session 7032162788712199: 1691893874625847; 0x7f2400005f50 0x7f2400004d40

[fancycode]

The error is the same (payload does not contain a valid sdp).

Could you please apply this patch and rebuild the signaling server? This will include the received payload in the message for further debugging:

diff --git a/clientsession.go b/clientsession.go
index 5dc1ec7..6f18382 100644
--- a/clientsession.go
+++ b/clientsession.go
@@ -775,7 +775,7 @@ func (s *ClientSession) isSdpAllowedToSendLocked(payload map[string]interface{})
 	}
 	sdpText, ok := sdpValue.(string)
 	if !ok {
-		return 0, &SdpError{"payload does not contain a valid sdp"}
+		return 0, &SdpError{fmt.Sprintf("payload %+v does not contain a valid sdp", payload)}
 	}
 	var sdp sdp.SessionDescription
 	if err := sdp.Unmarshal(sdpText); err != nil {

[dzatoah]

Oh, I think the Issue got fixed in master already. Cool. Thanks for your help. Do you know when you're releasing a new version?

Just in case heres the logfile: signaling3.log

[fancycode]

Just noticed you were still at 0.4.1, the latest release is 0.5.0 and should be close to master.

[dzatoah]

I can confirm, this is not an issue with Janus 1.x. I've successfully tested it over the internet with a friend. v0.5.0 works too. I'll write the maintainer of the debian package, hopefully he has time to update the upstream version. ^^ Thank you!! Closing this Issue now.

[dzatoah]

Reopening this issue. It won't be possible for a while to have nextcloud-spreed-signaling 0.5.0 in Debian testing/unstable. Due to build requirement change on etcd >= 3.5.7 which is not in Debian, yet.

Hopefully we can just cherry-pick a fix for this issue and patch the 0.4.1 version in debian.

I'll provide the log you asked for with the patch above applied soon.

[fancycode]

The signaling server doesn't need to depend on etcd directly. The Go module dependency is fetched together with the various other dependencies while building.

[sunweaver]

So, if signaling does not need etcd, could you clean up go.mod etc. and provide a clean-up dependency list? We want to ship latest nextcloud-spreed-signaling in Debian testing/unstable. However, the hard dependency on etcd 3.5.7 is currently a show stopper.

[fancycode]

Sorry for not being clearer. While the signaling server doesn't hard-depend on the etcd service, it does depend on the etcd Go modules as defined in go.mod. This modules are fetched while building similar to other Go modules (e.g. gorilla mux, etc.).

Would it help to provide release tarballs with vendored dependencies for future releases?

[sunweaver]

Unfortunately, vendored tarballs are not helpful in Debian, because Debian policy forbids code duplications. Every Go module needs to be packaged individually.

[dzatoah]

Results after a bit of testing: Nextcloud v24.0.1 / Talk 14.0.3 (Works) Nextcloud v24.0.1 / Talk 14.0.2 (Doesn't work) Nextcloud v24.0.1 / Talk 14.0.3 (Doesn't work, new error)

backend_client.go:389: Could not decode OCS response body [] from https://<MY_SERVER_FQDN>/ocs/v2.php/apps/spreed/api/v3/signaling/backend: parse error: expected { near offset 1 of ''

Nextcloud v24.0.3 / Talk 14.0.3 (Doesn't work)

Very confusing results... The signaling server wasn't touched at all and stayed at v0.4.1.

[dzatoah]

While trying to build n-s-s in Debian Bullseye with golang-go 1.18 I'm facing the following issue:

> make                                                         
GOPATH="nextcloud-spreed-signaling/vendor:nextcloud-spreed-signaling" /usr/bin/go get -u github.com/mailru/easyjson/...
go: downloading github.com/mailru/easyjson v0.7.7
go: downloading github.com/josharian/intern v1.0.0
PATH=/usr/bin:/home/daniel/.local/bin:/home/daniel/.config/rofi/bin:/home/daniel/.poetry/bin:/home/daniel/.cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games GOPATH="nextcloud-spreed-signaling/vendor:nextcloud-spreed-signaling" "nextcloud-spreed-signaling/vendor/bin/easyjson" -all api_signaling.go
/bin/sh: 1: nextcloud-spreed-signaling/vendor/bin/easyjson: not found
make: *** [Makefile:88: api_signaling_easyjson.go] Fehler 127

So go get -u github.com/mailru/easyjson/ seems to fail, even if I try it manually. (vendor/bin doesn't exist)

[fancycode]

While trying to build n-s-s in Debian Bullseye with golang-go 1.18 I'm facing the following issue:

Which version of n-s-s and how are you building it?

[fancycode]

Unfortunately, vendored tarballs are not helpful in Debian, because Debian policy forbids code duplications. Every Go module needs to be packaged individually.

Ok, so unfotunately you will have to wait until the dependency packages in Debian are updated or add a patch to still support the older version of etcd.

[fancycode]

Btw, I checked your patch in the Debian packaging and the support for newer versions of github.com/pion/sdp was incorrect:

--- a/clientsession.go
+++ b/clientsession.go
@@ -715,7 +715,7 @@
        if !found {
                return 0, &SdpError{"payload does not contain a sdp"}
        }
-       sdpText, ok := sdpValue.(string)
+       sdpText, ok := sdpValue.([]byte)
        if !ok {
                return 0, &SdpError{"payload does not contain a valid sdp"}
        }

This could be the reason for the initial error payload does not contain a valid sdp you reported here.

See #301 for support of github.com/pion/sdp v3.0.5.

[dzatoah]

Interesting... I can't even build with this patch.

(I had to alter the Makefile because I have golang-go 1.18 installed. See below)

root@nextcloud-hpb-setpu:~/nextcloud-spreed-signaling# git diff
diff --git a/Makefile b/Makefile
index 9b05ba4..673a660 100644
--- a/Makefile
+++ b/Makefile
@@ -47,7 +47,7 @@ hook:
        [ ! -d "$(CURDIR)/.git/hooks" ] || ln -sf "$(CURDIR)/scripts/pre-commit.hook" "$(CURDIR)/.git/hooks/pre-commit"
 
 ./vendor/bin/easyjson:
-       GOPATH=$(GOPATH) $(GO) get -u github.com/mailru/easyjson/...
+       GOPATH=$(GOPATH) $(GO) get -u github.com/mailru/easyjson/... && GOPATH=$(GOPATH) $(GO) install github.com/mailru/easyjson/...@latest
 
 continentmap.go:
        $(CURDIR)/scripts/get_continent_map.py $@
diff --git a/clientsession.go b/clientsession.go
index 0e24176..87bbec1 100644
--- a/clientsession.go
+++ b/clientsession.go
@@ -715,7 +715,7 @@ func (s *ClientSession) isSdpAllowedToSendLocked(payload map[string]interface{})
        if !found {
                return 0, &SdpError{"payload does not contain a sdp"}
        }
-       sdpText, ok := sdpValue.(string)
+       sdpText, ok := sdpValue.([]byte)
        if !ok {
                return 0, &SdpError{"payload does not contain a valid sdp"}
        }
root@nextcloud-hpb-setpu:~/nextcloud-spreed-signaling# make
PATH=/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin GOPATH="/root/nextcloud-spreed-signaling/vendor:/root/nextcloud-spreed-signaling" "/root/nextcloud-spreed-signaling/vendor/bin/easyjson" -all api_proxy.go
# github.com/strukturag/nextcloud-spreed-signaling
./clientsession.go:723:26: cannot use sdpText (variable of type []byte) as type string in argument to sdp.Unmarshal
Bootstrap failed: exit status 2
make: *** [Makefile:88: api_proxy_easyjson.go] Error 1

[dzatoah]

My self built 0.4.1 n-s-s:

2022-08-04 13:09:59.061240 I | client.go:282: Client from 31.220.65.91 has RTT of 90 ms (90.206084ms)
2022-08-04 13:09:59.063608 I | hub.go:809: Invalid message {Id: Type: Hello:<nil> Bye:<nil> Room:<nil> Message:<nil> Control:<nil> Internal:<nil>} from 31.220.65.91: type missing
2022-08-04 13:10:01.397025 I | client.go:303: Error reading from 31.220.65.91: read tcp 127.0.0.1:1270->127.0.0.1:60194: use of closed network connection

On debian's version there's no such error.

[fancycode]

My self built 0.4.1 n-s-s:

2022-08-04 13:09:59.061240 I | client.go:282: Client from 31.220.65.91 has RTT of 90 ms (90.206084ms)
2022-08-04 13:09:59.063608 I | hub.go:809: Invalid message {Id: Type: Hello:<nil> Bye:<nil> Room:<nil> Message:<nil> Control:<nil> Internal:<nil>} from 31.220.65.91: type missing
2022-08-04 13:10:01.397025 I | client.go:303: Error reading from 31.220.65.91: read tcp 127.0.0.1:1270->127.0.0.1:60194: use of closed network connection

On debian's version there's no such error.

See #180 for the type missing error. Anyway, this sounds more like a problem of your custom build environment and not really of the signaling server. Feel free to reopen with additional details or provide a pull-request if you need changes in the Makefile or other components.