From Mozilla doc it says
"closed": The ICE agent for this RTCPeerConnection has shut down and is
no longer handling requests.
When or how does a RTCPeerConnection gets shut down
This state will in general not fire. The only way to reach it is to call the close() method on the RTCPeerConnection and calling close will not fire events. Try this:
const pc = new RTCPeerConnection();
pc.close();
pc.iceConnectionState;
Related
"peerConnection new connection state: connected"
{
"janus": "webrtcup",
"session_id": 3414770196795261,
"sender": 4530256184020316
}
{
"janus": "media",
"session_id": 3414770196795261,
"sender": 4530256184020316,
"type": "audio",
"receiving": true
}
... 1 minute passes
"peerConnection new connection state: disconnected"
{
"janus": "timeout",
"session_id": 3414770196795261
}
"peerConnection new connection state: failed"
See pastebin for the full logs.
I'm trying to join a videoroom on my Janus server. All requests seem to succeed, and my device shows a connected WebRTC status for around one minute before the connection is canceled because of a timeout.
The WebRTC connection breaking off seems to match up with the WebSocket connection to Janus' API breaking.
I tried adding a heartbeat WebSocket message every 10 seconds, but that didn't help. I'm
joining the room
receiving my local SDP plus candidates
configuring the room with said SDP
receiving an answer from janus
accepting that answer with my WebRTC peer connection.
Not sure what goes wrong here.
I also tried setting a STUN server inside the Janus config, to no avail. Same issue.
Added the server logs to the pastebin too.
RTFM: Janus' websocket connections require a keepalive every <60s.
An important aspect to point out is related to keep-alive messages for WebSockets Janus channels. A Janus session is kept alive as long as there's no inactivity for 60 seconds: if no messages have been received in that time frame, the session is torn down by the server. A normal activity on a session is usually enough to prevent that; for a more prolonged inactivity with respect to messaging, on plain HTTP the session is usually kept alive through the regular long poll requests, which act as activity as long as the session is concerned. This aid is obviously not possible when using WebSockets, where a single channel is used both for sending requests and receiving events and responses. For this reason, an ad-hoc message for keeping alive a Janus session should to be triggered on a regular basis. Link.
You need to send 'keepalive' message with same 'session_id'to keep the session going. Janus closes session after 60 seconds.
Look for the implementation: https://janus.conf.meetecho.com/docs/rest.html
Or do it my way: i do it every 30 seconds in a runnable handler.
private Handler mHandler;
private Runnable fireKeepAlive = new Runnable() {
#Override
public void run() {
String transactionId = getRandomStringId();
JSONObject request = new JSONObject();
try {
request.put("janus", "keepalive");
request.put("session_id", yourSessionId);
request.put("transaction", transactionId);
} catch (JSONException e) {
e.printStackTrace();
}
myWebSocketConnection.sendTextMessage(request.toString());
mHandler.postDelayed(fireKeepAlive, 30000);
}
};
Then in OnCreate()
mHandler = new Handler();
then call this where WebSocket connection Opens:
mHandler.post(fireKeepAlive);
be sure to remove callback on destroy
mHandler.removeCallbacks(fireKeepAlive);
When my client successfully connects to the hub, I want the client to immediately join a group. I have a method in my hub to do that, I just need an event handler for when the connection is established, just like
connection.start().done(
function () {
connection.invoke('JoinGroup', 'GroupName');
});
in SignalR for plain ASP.Net.
Can I do that or do I have to set a timer to do it after x seconds after the start(); call was made?
Edit:
I found out I can do
connection.start(
function (){
connection.invoke('JoinGroup', 'GroupName');
}
);
but it tells me that it Cannot send data if the connection is not in the 'Connected' State.
what do?
SignalR is notoriously difficult due to version mismatches etc.
Please see the following article: https://learn.microsoft.com/en-us/aspnet/core/tutorials/signalr?view=aspnetcore-2.1&tabs=visual-studio
In it, there's a section that specifies how to start (and wait for connection to be established):
var connection = new signalR.HubConnectionBuilder().withUrl("/chatHub").build();
connection.start().then(() => {
//try some stuff here :)
})
.catch(function (err) {
//failed to connect
return console.error(err.toString());
});
The javascript client uses promises that have to be resolved/rejected before you can use it.
The other option is to wrap inside async method and await the call (not sure if this will work correctly). Such as:
await connection.start();
//connection should be started now. beware of exceptions though
I have a WCF Duplex net.tcp binding. I create a client DuplexClient to comuunicate with server. If, for some reason the service stop responding (app pool recycles for exemple) between the client creation and the method call, I get a weird behavior.
try
{
var result = await client.SomeMethod();
}
catch (Exception ex)
{
Console.WriteLine($"client.State = {client.State}");
Console.WriteLine($"Error : {ex.Message}");
}
I have this message in the console :
client.State = Opened
Error : The communication object,
System.ServiceModel.Channels.ClientFramingDuplexSessionChannel, cannot
be used for communication because it is in the Faulted state.
How can the channel be in the state Opened while the error says that it is in a Faulted state ? I strongly suspect the ClientFramingDuplexSessionChannel type because it probably keeps an open channel from server to client while the client to server channel is dead. Is it possible ? How can I check if client is realy opened and running both ways ?
I am working on a .net client application which utilizes SignalR. I want to notify the user if the connection is down for some reason. How can I capture the disconnect event using the native client?
The client will go into the reconnecting when the connection dies.
Therefore you can tie into the Reconnecting event to see when the connection goes down:
var connection = new Connection("http://myEndPointURL");
connection.Reconnecting += () =>
{
Console.WriteLine("The connection has gone down, shifting into reconnecting state");
};
Hope this helps!
I was able to capture StateChanged to detect changes in the connection and notify the user.
connection.StateChanged += (statechange) =>
{
Console.WriteLine("Changing from " + statechange.OldState + " to " + statechange.NewState);
};
This gives me a mechanism to notify the user when the connection is dropped or successfully reconnected.
I'm using OperationContext.Current.GetCallbackChannel to get a channel to the client that called a WCF service operation.
Do I need to worry about closing / disposing these callback channels or is this taken care of by the framework?
Well, I just tried it myself and it turns out that if you Close & Dispose the callback channel (after casting to IClientChannel) the entire Service channel becomes useless and when called throws a ProtocolException saying:
"This channel can no longer be used to send messages as the output session was auto-closed due to a server-initiated shutdown. Either disable auto-close by setting the DispatchRuntime.AutomaticInputSessionShutdown to false, or consider modifying the shutdown protocol with the remote server."
I assume that this is an unwelcome consequence or side effect of attempting to close & dispose the callback channel, meaning that this should not be done.
In my opinion you should.
The callback mechanism supplies nothing like a higher-level protocol for managing the
connection between the service and the callback endpoint. It is up to the developer to
come up with some application-level protocol or a consistent pattern for managing the
lifecycle of the connection. The service can only call back to the client if the client-side channel is still open, which is typically achieved by not closing the proxy. Keeping the proxy open will also prevent the callback object from being garbage-collected. If the service maintains a reference on a callback endpoint and the client-side proxy is closed or the client application itself is gone, when the service invokes the callback it will get an ObjectDisposedException from the service channel. It is therefore preferable for the client to inform the service when it no longer wishes to receive callbacks or when the client application is shutting down. To that end, you can add an explicit Disconnect() method to the service contract. Since every method call carries the callback reference with it, in the Disconnect() method the service can remove the callback reference from its internal store.
here is an exemple :
class MyService : IServiceContract
{
static List<IServiceContractCallback> m_Callbacks = new List<IServiceContractCallback>();
public void Connect()
{
IServiceContractCallbackcallback = OperationContext.Current.GetCallbackChannel<IServiceContractCallback>();
if(m_Callbacks.Contains(callback) == false)
{
m_Callbacks.Add(callback);
}
}
public void Disconnect()
{
IServiceContractCallback callback = OperationContext.Current.GetCallbackChannel<IServiceContractCallback>();
if(m_Callbacks.Contains(callback))
{
m_Callbacks.Remove(callback);
}
else
{
throw new InvalidOperationException("Cannot find callback");
}
}
In such a way a client can inform the service that the callback is no longer needed. Does it answer your question ?