https://livekit.io logo
Join Slack
Powered by
This message was deleted.
# sdk-rust
s
This message was deleted.
e
I connect by calling:
Copy code
signal_client::SignalClient::connect(&host, &auth_token, options).await
It connects successfully and I get a 
JoinResponse
, a 
SignalClient
and a 
UnboundedReceiver<SignalEvent>
. I can publish tracks, stream stuff, things work fine until exactly 1min after the connection, when I get this:
Copy code
> livekit signal < Leave(LeaveRequest { can_reconnect: false, reason: JoinFailure })
and then I receive a 
SignalEvent::Close()
what am I doing wrong?
I get some PongResp messages so I guess the SignalClient seems to be sending pings, and in the 
JoinResponse
it says:
Copy code
ping_timeout: 15, ping_interval: 5
so I guess it's not a ping issue otherwise it would not take 1 min
one note, I receive this a little after joining:
Copy code
> livekit signal < Update(ParticipantUpdate { participants: [ParticipantInfo { sid: "PA_N9y2swDPr6S8", identity: "preview-identity", state: Joined, tracks: [], metadata: "", joined_at: 1699042748, name: "preview", version: 1, permission: Some(ParticipantPermission { can_subscribe: false, can_publish: true, can_publish_data: true, can_publish_sources: [], hidden: false, recorder: false, can_update_metadata: false }), region: "dfra1a", is_publisher: false }] })
so the server tells me my state is 
Joined
a
I’m not super familiar with the rust client but why are you calling 
SignalClient::connect
rather than 
Room::connect
?
d
are you publishing anything? do you have a reproducible example?
e
this 1min disconnection also happens if I don't try to publish any track, nor forward any sdp message
d
are you seeing this behavior only with Cloud? or is this happening to a locally hosted livekit install too? Is there an example session where this happens? I can take a look at the logs on our side to see if I can spot anything
e
I only tried using livekit cloud so far, but indeed it's a good idea to try hosting livekit locally to compare/look at the logs
session: RM_TU7e2qQN5YGq participant: _PA_dD8yZYkjps78_
a
can you also share the WS URL for the project you’re using?
e
yep, by running locally I can see the logs on the server! love that
Copy code
2023-11-04T23:23:40.675+0100    ERROR   livekit supervisor/participant_supervisor.go:156    supervisor error on publication {"room": "c47bfcce-5f4f-4906-966f-9dee7b840196", "roomID": "RM_8CQqu9MgQQqj", "participant": "preview-test", "pID": "PA_NWF7RLqTnd3U", "remote": false, "trackID": "TR_AMXy6KuSWwFyzE", "error": "publish time out"}
now will try to figure out why this is happening
apparently the publish timeout is not the only issue
there's also a join timeout
Copy code
{
  "room": "c47bfcce-5f4f-4906-966f-9dee7b840196",
  "roomID": "RM_QxRgMvsqzEHt",
  "participant": "preview-test",
  "pID": "PA_cbad6L5Ej6WT",
  "remote": false,
  "sendLeave": true,
  "reason": "JOIN_TIMEOUT",
  "isExpectedToResume": false,
  "clientInfo": "sdk:RUST protocol:9 address:\"192.168.1.4\""
}
d
yeah I see the same thing on the cloud side too. I don't think the webrtc connection has actually succeeded
there are two webrtc connections: publisher and subscriber. if subscriber doesn't connect, it'll raise a JOIN_TIMEOUT and disconnect the signal if you started to publish, but no bits were sent, it'll fail due to publish failure
e
I think the connection for the media channels succeeded, as I can watch the h264 stream live on the call
the issue seems to be that the participant state never switches to ACTIVE, stays on JOINED
and the root cause seems to be that I'm not opening a data channel (e.g: _lossy)
it seems to be required to open this data channel otherwise it never switches to ACTIVE
d
is this for the publish stream? or subscribe?
e
I'm only creating one connection, to publish tracks
not sure if that's what you mean by publish or subscribe stream
d
hmm that seems to be a problem then.. I think it's expecting a subscribe connection in order to flip it to ACTIVE
e
is that a second SignalClient connection? or a data channel?
d
that's PeerConnection
e
hmm I see
d
in order to avoid that requirement... you would need to create a token with 
canSubscribe: false
👀 1
that'll indicate to the server that only publish peerconnection should be used
e
let me test that!
d
e
Copy code
let grants = VideoGrants {
                room_join: true,
                can_subscribe: false,
                room: self.instance_task.studio_session_uuid.clone(),
                ..Default::default()
            };
that seems to be the case already 🤔
yeah the token is being generated with can_subscribe = false
d
hmm ok.. I think this is a nonstandard case that we'll have to dig in to see.. I would love for us to support publish only mode properly tho
do you mind opening a GH issue under livekit/livekit ? if you are interested in contributing to make it happen, I'd welcome it!
🙌 1
e
of course! thank you david!
after some more debugging, found out the issue wasn't with the subscriber peer connection
the issue is that the participant is not switching from JOINED to ACTIVE until a data channel is open
Copy code
func (t *PCTransport) isFullyEstablished() bool {
	t.lock.RLock()
	defer t.lock.RUnlock()

	return t.reliableDCOpened && t.lossyDCOpened && !t.connectedAt.IsZero()
}
is the data channel really required?
maybe the data channels should be optional and handled separately?
Copy code
func (t *PCTransport) isFullyEstablished() bool {
    t.lock.RLock()
    defer t.lock.RUnlock()

    return !t.connectedAt.IsZero()
}
maybe we should add a parameter to know if the participant wants data channels? (maybe there's one already?)
Open in Slack
PreviousNext
Powered by