I have a chat application developed by oc.I'm currently using pjsip library to register to a SIP server using PJSIP.I use pjsua_call_make_call to make videoCall,and use pjsua_call_hangup to hangup call.when network is reachable,everything is ok .This is a problem when network disconnected. Below are steps to reproduce(audiocall is ok and i have search similar problems but no results) :
make videoCall to other,other answer the call to change videoCall state to confirmed
i disconnected network
i hangup videocall
then issue appear:thread will be blocked,hangup failure
below are log:
14:21:35.527 tsx0x1042f82a8 ....Failed to send Request msg BYE/cseq=2 (tdta0x1042c2ea8)! err=120051 (Network is unreachable)
14:21:35.527 tsx0x1042f82a8 ....State changed from Null to Terminated, event=TRANSPORT_ERROR
14:21:35.527 dlg0x10411a6a8 .....Transaction tsx0x1042f82a8 state changed to Terminated
14:21:35.527 Pjsua_call.c .......im pjsua_call_get_info get Date Wed, 09 Aug 2017 06:21:06 GMT
14:21:35.527 Pjsua_call.c .......im pjsua_call_get_info get call_info 1
14:21:35.537 strm0x1042c7a28 !Starting silence
14:21:35.569 pjsua_media.c !.......Call 0: deinitializing media..
14:21:35.569 strm0x1042c7a28 .........JB summary:size=0/eff=0 prefetch=0 level=10 delay (min/max/avg/dev)=360/500/425/45 ms burst (min/max/avg/dev)=1/11/2/2 frames lost=25 discard=29 empty=218
14:21:35.569 pjsua_media.c .........Media stream call00:0 is destroyed
14:21:35.569 pjsua_vid.c .........Stopping video stream..
14:21:35.609 darwin_dev.m ..........Stopping Darwin video stream
14:21:35.663 pjsua_vid.c ..........Window 1: destroying..
14:21:35.663 vid_port.c ...........Closing Front Camera..
Related
I have a PM sensor, made for the initiative "sensor community", outside the window, attached to an ESP8266 which connected to a repeater that repeats my home network. Yesterday morning I noticed that suddenly it wasn't publishing the values anymore.
Today I reflashed the board, which is an Adafruit Huzzah with an ESP8266 on board, with the basic example WiFiClientBasic from the ESP82666 library switching on the serial debug of the WiFi.
void setup() {
Serial.begin(115200);
// We start by connecting to a WiFi network
WiFi.mode(WIFI_STA);
WiFiMulti.addAP(ssid, password);
Serial.println();
Serial.println();
Serial.print("Wait for WiFi... ");
while (WiFiMulti.run() != WL_CONNECTED) {
Serial.print(".");
delay(500);
}
Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());
delay(500);
}
The debug yields continuously this error:
[WIFI] Connecting BSSID: SSID: Channel: 6 (-39)
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 0 (12)
wifi evt: 1
STA disconnect: 203
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 0 (12)
wifi evt: 1
STA disconnect: 203
reconnect
Another ESP8266 board (a LOLIN Wemos) that had the same configuration refuses to connect. Other devices connected to the same network (my 2 laptops, an Android tablet, a Raspberry Pi) don't have any troubles.
The repeater has a DHCP running and has no problem in releasing IP to other devices. Assigning the ESP8266 a static IP, both on the board and/or on the repeater, has no effect.
I'm not a network expert, but those are the main configs of the repeater (a rather old Digicom REW300).
WLAN STATUS Infrastructure Client --- (Connected)
Signal Strenght 54%
Channel-Band 2.4GHz (G+N) channel 6
Rate 13Mbps (MCS1)
Encryption WPA2-PSK
Repeater Status
WLAN STATUS AP --- (Enabled)
Rate auto
Encryption WPA2-PSK
I also looked at the log on the repeater:
Mar 19 16:01:12 DIGICOM-REW300-Z01 user.warn kernel: wlan0-vxd: A wireless client is deauthenticated - "MAC address of the ESP8266"
Mar 19 16:01:13 DIGICOM-REW300-Z01 user.warn kernel: wlan0-vxd: A wireless client is deauthenticated - "MAC address of the ESP8266"
Mar 19 16:01:15 DIGICOM-REW300-Z01 user.warn kernel: wlan0-vxd: A wireless client is deauthenticated - "MAC address of the ESP8266"
I didn't change the settings of the repeater recently, however yesterday morning the ISP changed the main router with a newer one. I think that could be the problem, but anyway the ESP8266 isn't connecting directly to it (it's too far away) but to the repeater which didn't change at all. Moreover: if I take the ESP8266 inside, it can connect to the main router without any troubles. It seems that the combination of new router and old repeater caused the problem, and just only for the ESP8266s. The only thing that changed from the old router is that the new one has only band G+N only, while the old one had B+G+N, I don't think it matters anyway, as it can be connected directly, and the old repeater is B+G+N.
The official docs from Espressif says that error 203 is ASSOC_FAIL, which is a rather generic error.
Further test I did: if the repeater is tethered with my mobile, the ESP8266 connects.
So:
ESP8266 to repeater to WAN (broken)
ESP8266 to WAN (OK)
ESP8266 to repeater to Mobile Phone to WAN (OK)
Maybe add these lines can help...
WiFi.setAutoReconnect(true);
WiFi.persistent(true);
Here an example with reconection and status connection
I have problem connecting to janus janus.plugin.videoroom plugin from iOS device using swift.
Although every steps take place correctly but janus server send following message:
{
"janus": "hangup",
"session_id": 3201104494179497,
"sender": 7759980289270843,
"reason": "ICE failed"
}
and disconnect.
Debugging the messages of connecting to janus leads me to following:
1- RTCIceGatheringState never changes to Completed
2- The generated candidates are like following:
candidate:3215141415 1 udp 1686052607 w.x.y.z 57168 typ srflx raddr w.x.y.z rport 57168 generation 0 ufrag 340a network-id 1 network-cost 10
as you can see video and audio words are replaced by 1 and 0 respectively in the generated candidate.
Do you have any idea about these two observations!
And why janus send the "ICE failed" message?
I found that the reason of getting "hang up" message is because I did not set the received jsep (from janus) to my peerconnection.
after setAnswer the jsep "hang up" message gone!
1- RTCIceGatheringState never changes to Completed
For the problem of not having "Completed" state For RTCIceGatheringState was because of "continualGatheringPolicy" options in configuring the peerConnection which was set to "gatherContinually" after setting that to "gatherOnce" the Completed state seen! :)
2- The generated candidates are like following:
It seem this is normal to have audio/video or 0/1
We are using Lettuce in our project. We have a requirement to monitor the status of connection.
I know Lettuce can re-connect Redis when the connection is down. But is there some way to notify application that the connection is down/up?
Thanks,
Steven
Lettuce provides an event-model for connection events. You can subscribe to the EventBus and react to events published on the bus. There are multiple events, but for your case, you'd want to listen to connected and disconnected events:
ConnectionActivatedEvent: The logical connection is activated and can be used to dispatch Redis commands (SSL handshake complete, PING before activating response received)
ConnectionDeactivatedEvent: The logical connection is deactivated. The internal processing state is reset and the isOpen() flag is set to false.
Both events are fired after receiving Transport-related events such as ConnectedEvent respective DisconnectedEvent.
The following example illustrates how to consume these events:
RedisClient client = RedisClient.create()
EventBus eventBus = client.getresources().eventBus();
Disposable subscription = eventBus.get().subscribe(e -> {
if (e instanceOf ConnectionActivatedEvent) {
// …
}
});
…
subscription.dispose();
client.shutdown();
Please note that events are dispatched asynchronously. Anything that happens in the event listener should be non-blocking (i.e. if you need to call blocking code such as further Redis interaction, please offload this task to a dedicated Thread).
Read more
Lettuce Reference Documentation: Events
The documentation for mqtt.client:connect() states that the last arg is a "callback function for when the connection could not be established".
I have a case where mqtt.client:connect() succeeds, so the "not established" callback is not called (correct behavior). But, later, when my mqtt broker goes down, the "not established" callback function gets unexpectedly activated.
I have the following code:
function handle_mqtt_error (client, reason)
print("mqtt connect failed, reason = "..reason..". Trying again shortly.")
tmr.create():alarm(10 * 1000, tmr.ALARM_SINGLE, do_mqtt_connect)
end
function do_mqtt_connect ()
print("connecting---")
m:connect(MQTT_HOST, MQTT_PORT, 1, function(client)
print("mqtt connected")
client:publish("topic/status", "online", 1, 1)
end,
handle_mqtt_error
)
print("returning---")
end
-- init mqtt client
m = mqtt.Client(MQTT_CLIENT_ID, 120, MQTT_USER, MQTT_PASS)
-- connect to mqtt
print("Starting Test")
do_mqtt_connect()
I see the output from the test begin, as expected, with:
Starting Test
connecting---
returning---
mqtt connected
At this point, I kill my mqtt broker, and I unexpectedly see:
mqtt connect failed, reason = -5. Trying again shortly.
connecting---
returning---
mqtt connect failed, reason = -5. Trying again shortly.
connecting---
returning---
And, happily, but unexpectedly, when I restart my broker, I see:
mqtt connected
So, it appears that handle_mqtt_error() is not only called "when the connection could not be established". It appears that it also be called if mqtt.client:connect() successfully establishes a connection, then the connection is later broken.
======= New Information =======
I downloaded the "dev" tree and used the Docker image to build the firmware. Within mqtt.c, I enabled NODE_DBG. The interesting lines are:
enter mqtt_socket_reconnected.
mqtt connect failed, reason = -5. Trying again shortly.
enter mqtt_socket_disconnected.
leave mqtt_socket_disconnected.
leave mqtt_socket_reconnected.
The "mqtt connect failed..." message is printed by handle_mqtt_error(), which is my "connect failed" callback.
Here's my theory. When my test starts, do_mqtt_connect() calls mqtt_socket_connect(), which does this:
espconn_regist_reconcb(pesp_conn, mqtt_socket_reconnected);
This sets reconnect_callback (in app/lwip/app/espconn.c). Later, after my broker goes down and comes back up, espconn_tcp_reconnect() is called (in app/lwip/app/espconn_tcp.c). It calls the reconnect_callback, which is mqtt_socket_reconnected(), which calls handle_mqtt_error().
So, I think the end result doesn't match the documentation, but it works out okay for me. If the behavior did match the documentation, I would just add some Lua code to handle the "offline" event, and try to reestablish the mqtt connection. I just thought someone might be interested if the behavior doesn't match the documentation.
I install kafka on a standalone server and try to stream data to mongodb.
when start kafka service, bin/kafka-server-start.sh config/server.properties
I had a warning:
WARN Attempting to send response via channel for which there is no open connection, connection id 0 (kafka.network.Processor)
Even though, there is no problem for data entered at producer and displayed at consumer.
but I think this cause the data write to mongodb. I have no data write to mongodb after start data streaming.
anyone can help with this issue? Thank you so much.
//processor.sendResponse
protected[network] def sendResponse(response: RequestChannel.Response) {
trace(s"Socket server received response to send, registering for write and sending data: $response")
val channel = selector.channel(response.responseSend.destination)
// `channel` can be null if the selector closed the connection because it was idle for too long
if (channel == null) {
warn(s"Attempting to send response via channel for which there is no open connection, connection id $id")
response.request.updateRequestMetrics()
}
else {
selector.send(response.responseSend)
inflightResponses += (response.request.connectionId -> response)
}
so, channel was closed by the selector because it was idle too long