We were using Twilio Video for development of our system, I am able to use the system with my own laptop but working laptops have an error while trying to connect with Chrome browser.
I am getting below error:
WebSocket connection to 'wss://endpoint.twilio.com/' failed: Error during WebSocket handshake: 'Upgrade' header is missing
The full error text is below:
twilio-video.js:20135 WebSocket connection to 'wss://endpoint.twilio.com/' failed: Error during WebSocket handshake: 'Upgrade' header is missing
connect # twilio-video.js:20135
Transport # twilio-video.js:20025
(anonymous) # twilio-video.js:21181
twilio-video.js:14542 Tue Nov 28 2017 11:07:49 GMT+0300 (Turkey Standard Time) | sip.transport | WebSocket connection error: {"isTrusted":true}
LoggerFactory.print # twilio-video.js:14542
LoggerFactory.(anonymous function) # twilio-video.js:14559
Logger.(anonymous function) # twilio-video.js:14553
onError # twilio-video.js:20315
ws.onerror # twilio-video.js:20155
twilio-video.js:14542 Tue Nov 28 2017 11:07:49 GMT+0300 (Turkey Standard Time) | sip.transport | WebSocket disconnected (code: 1006)
twilio-video.js:14542 Tue Nov 28 2017 11:07:49 GMT+0300 (Turkey Standard Time) | sip.transport | WebSocket abrupt disconnection
LoggerFactory.print # twilio-video.js:14542
LoggerFactory.(anonymous function) # twilio-video.js:14559
Logger.(anonymous function) # twilio-video.js:14553
onClose # twilio-video.js:20204
ws.onclose # twilio-video.js:20147
twilio-video.js:14542 Tue Nov 28 2017 11:07:49 GMT+0300 (Turkey Standard Time) | sip.ua | transport wss://endpoint.twilio.com failed | connection state set to 2
twilio-video.js:14542 Tue Nov 28 2017 11:07:49 GMT+0300 (Turkey Standard Time) | sip.ua | next connection attempt in 28 seconds
twilio-video.js:14542 Tue Nov 28 2017 11:08:17 GMT+0300 (Turkey Standard Time) | sip.transport | connecting to WebSocket wss://endpoint.twilio.com
twilio-video.js:20135 WebSocket connection to 'wss://endpoint.twilio.com/' failed: Error during WebSocket handshake: 'Upgrade' header is missing
connect # twilio-video.js:20135
Transport # twilio-video.js:20025
(anonymous) # twilio-video.js:21181
twilio-video.js:14542 Tue Nov 28 2017 11:08:19 GMT+0300 (Turkey Standard Time) | sip.transport | WebSocket connection error: {"isTrusted":true}
LoggerFactory.print # twilio-video.js:14542
LoggerFactory.(anonymous function) # twilio-video.js:14559
Logger.(anonymous function) # twilio-video.js:14553
onError # twilio-video.js:20315
ws.onerror # twilio-video.js:20155
twilio-video.js:14542 Tue Nov 28 2017 11:08:19 GMT+0300 (Turkey Standard Time) | sip.transport | WebSocket disconnected (code: 1006)
twilio-video.js:14542 Tue Nov 28 2017 11:08:19 GMT+0300 (Turkey Standard Time) | sip.transport | WebSocket abrupt disconnection
LoggerFactory.print # twilio-video.js:14542
LoggerFactory.(anonymous function) # twilio-video.js:14559
Logger.(anonymous function) # twilio-video.js:14553
onClose # twilio-video.js:20204
ws.onclose # twilio-video.js:20147
twilio-video.js:14542 Tue Nov 28 2017 11:08:19 GMT+0300 (Turkey Standard Time) | sip.ua | transport wss://endpoint.twilio.com failed | connection state set to 2
twilio-video.js:14542 Tue Nov 28 2017 11:08:19 GMT+0300 (Turkey Standard Time) | sip.ua | next connection attempt in 30 seconds
twilio-video.js:14542 Tue Nov 28 2017 11:08:49 GMT+0300 (Turkey Standard Time) | sip.transport | connecting to WebSocket wss://endpoint.twilio.com
We do not even understand what is the problem actually.
This error message means that you are trying to connect to a HTTP server and not to a WebSocket server.
Possible reasons:
The URI you are using is not correct (in the past i have seen correct twilio websocket URI in this format: wss://xxx.endpoint.twilio.com. In your example the xxx part is missing)
You are behind some HTTP proxy which doesn't support WebSocket
Related
I'm using elasticdump and got weird error
Mon, 14 Nov 2022 14:42:21 GMT | starting dump
Mon, 14 Nov 2022 14:42:22 GMT | got 10 objects from source elasticsearch (offset: 0)
Mon, 14 Nov 2022 14:42:22 GMT | sent 10 objects to destination file, wrote 10
Mon, 14 Nov 2022 14:42:22 GMT | Error Emitted => This and all future requests should be directed to the given URI.
Mon, 14 Nov 2022 14:42:22 GMT | Error Emitted => This and all future requests should be directed to the given URI.
Mon, 14 Nov 2022 14:42:22 GMT | Total Writes: 0
Mon, 14 Nov 2022 14:42:22 GMT | dump ended with error (get phase) => MOVED_PERMANENTLY: This and all future requests should be directed to the given URI.
It successfully moved 10 objects and stopped
--input-index is for a different use case.
Try with just --input like this
elasticdump --input=http://localhost/dev_index --output=test2.json
I've setup an Ubuntu 16.04 EC2 t2.medium server and followed the instructions here http://docs.bigbluebutton.org/2.0/20install.html to install BigBlueButton 2.0-beta.
When I log into the Demo Meeting room and select Microphone it says calling... then changes to connecting... and then I get a message saying:
WebRTC Audio Failure
Detected the following WebRTC issue: Error 1010: ICE negotiation
timeout. Do you want to try Flash instead?
Here is the output from the console:
BigBlueButton call accepted
bbb_webrtc_bridge_sip.js?v=591:497 Waiting for ICE negotiation
sip.js?v=591:2900 Thu Sep 21 2017 11:27:19 GMT+0800 (WITA) | sip.invitecontext.mediahandler | stream added: fuEOgOt7p5aHrW58wGtGVszgTdGBcNKi
sip.js?v=591:2900 Thu Sep 21 2017 11:27:24 GMT+0800 (WITA) | sip.invitecontext.mediahandler | RTCIceChecking Timeout Triggered after 5000 milliseconds
bbb_webrtc_bridge_sip.js?v=591:499 5 seconds without ICE finishing
bbb_webrtc_bridge_sip.js?v=591:119 Stopping webrtc audio test
bbb_webrtc_bridge_sip.js?v=591:555 Hanging up current session
sip.js?v=591:2900 Thu Sep 21 2017 11:27:24 GMT+0800 (WITA) | sip.inviteclientcontext | terminating Session
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.transport | sending WebSocket message:
BYE sip:919673089#172.31.36.135:5060;transport=udp SIP/2.0
Via: SIP/2.0/WSS msk2aa46iuih.invalid;branch=z9hG4bK7275105
Max-Forwards: 70
To: <sip:919673089#staging.bigbluebutton.xxxxxx.com>;tag=SBBF64e6999Hm
From: "w_zqmgpmdukz39-bbbID-Mikhail" <sip:w_zqmgpmdukz39-bbbID-Mikhail#staging.bigbluebutton.xxxxxx.com>;tag=d6e9kj05rj
Call-ID: epjgsffnq2hi688jlvgl
CSeq: 9777 BYE
Supported: outbound
User-Agent: BigBlueButton
Content-Length: 0
bbb_webrtc_bridge_sip.js?v=591:465 call ended null
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.inviteclientcontext | closing INVITE session epjgsffnq2hi688jlvglj9cdnvthcr
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.invitecontext.mediahandler | closing PeerConnection
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.dialog | dialog epjgsffnq2hi688jlvgld6e9kj05rjSBBF64e6999Hm deleted
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.ua | user requested closure...
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.ua | closing registerContext
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.registercontext | already unregistered
LoggerFactory.print # sip.js?v=591:2900
LoggerFactory.(anonymous function) # sip.js?v=591:2917
Logger.(anonymous function) # sip.js?v=591:2911
unregister # sip.js?v=591:3579
close # sip.js?v=591:3570
UA.stop # sip.js?v=591:8929
(anonymous) # bbb_webrtc_bridge_sip.js?v=591:505
setTimeout (async)
(anonymous) # bbb_webrtc_bridge_sip.js?v=591:498
EventEmitter.emit # sip.js?v=591:115
accepted # sip.js?v=591:5641
onSuccess # sip.js?v=591:6851
Promise resolved (async)
receiveInviteResponse # sip.js?v=591:6832
receiveResponse # sip.js?v=591:3784
InviteClientTransaction.receiveResponse # sip.js?v=591:7832
onMessage # sip.js?v=591:8566
ws.onmessage # sip.js?v=591:8424
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.transport | received WebSocket text message:
SIP/2.0 200 OK
Via: SIP/2.0/WSS msk2aa46iuih.invalid;branch=z9hG4bK7275105;received=52.51.xx.xx;rport=38902
From: "w_zqmgpmdukz39-bbbID-Mikhail" <sip:w_zqmgpmdukz39-bbbID-Mikhail#staging.bigbluebutton.xxxxxx.com>;tag=d6e9kj05rj
To: <sip:919673089#staging.bigbluebutton.xxxxxx.com>;tag=SBBF64e6999Hm
Call-ID: epjgsffnq2hi688jlvgl
CSeq: 9777 BYE
User-Agent: FreeSWITCH-mod_sofia/1.9.0+git~20170822T213300Z~2ebdf42f2c~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Content-Length: 0
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.transport | closing WebSocket wss://staging.bigbluebutton.xxxxxx.com/ws
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.transport | WebSocket disconnected (code: 1000)
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.ua | connection state set to 1
sip.js?v=591:2900 Thu Sep 21 2017 11:27:25 GMT+0800 (WITA) | sip.transaction.ict | transport error occurred, deleting INVITE client transaction z9hG4bK9694442
I've searched for anything related to bigbluebutton error 1010 but can't find anything.
Please check your firewall :
TCP ports 80, 443,and 1935 are accessible.
TCP port 7443 is accessible if you intend to configure SSL (recommended), otherwise port 5066 is accessible.
UDP ports 16384 - 32768 are accessible.
Port 80 is not in use by another application.
the problem is your sip ip and port.
Check /opt/freeswitch/etc/freeswitch/sip_profiles/external.xml settings firstly.
ws-binding: :5066
wss-binding: :7443
change it to like this:
ws-binding: your_external_ip_address:5066
wss-binding: your_external_ip_address:7443
Your external ip address is same with external_sip_ip address.
Then check your 5066 and 7443 port if you use firewall.
Then dont forget to restart bbb (bbb-conf --restart)
When I running a fluentd td-agent to read the data from the tcp port 514 using tcp plugin but I find the error as,
2015-05-25 15:32:18 +0000 [info]: adding match pattern="tcp.events" type="stdout"
2015-05-25 15:32:18 +0000 [info]: adding source type="tcp"
2015-05-25 15:32:18 +0000 [error]: unexpected error error_class=Errno::EACCES error=#<Errno::EACCES: Permission denied - bind(2) for "0.0.0.0" port 514>
When I try to read the data from TCP port I find the data as
nc -l 514
<30>May 25 21:15:11 5gws056 docker/34cead996122[1865]: Hello Mon May 25 15:45:11 UTC 2015
<30>May 25 21:15:12 5gws056 docker/34cead996122[1865]: Hello Mon May 25 15:45:12 UTC 2015
<30>May 25 21:15:13 5gws056 docker/34cead996122[1865]: Hello Mon May 25 15:45:13 UTC 2015
<30>May 25 21:15:14 5gws056 docker/34cead996122[1865]: Hello Mon May 25 15:45:14 UTC 2015
<30>May 25 21:15:15 5gws056 docker/34cead996122[1865]: Hello Mon May 25 15:45:15 UTC 2015
Thanks in advance
Any port number under 1024 requires root permission. It's called privileged ports. Could you try with bigger port number?
Jmeter is taking always the same time to finish remote test. The jmx script is simple and there is no time configured on it, and there are just one request (only 84ms in local test).
It happens only on remote test, in local test is ok.
Starting the test on host x.x.x.x # Thu Aug 14 09:31:43 BRT 2014 (1408019503091)
Finished the test on host x.x.x.x # Thu Aug 14 09:34:43 BRT 2014 (1408019683082)
Starting the test on host x.x.x.x # Thu Aug 14 09:35:53 BRT 2014 (1408019753107)
Finished the test on host x.x.x.x # Thu Aug 14 09:38:53 BRT 2014 (1408019933091)
Starting the test on host x.x.x.x # Thu Aug 14 09:40:33 BRT 2014 (1408020033110)
Finished the test on host x.x.x.x # Thu Aug 14 09:43:33 BRT 2014 (1408020213100)
Starting the test on host x.x.x.x # Thu Aug 14 10:03:23 BRT 2014 (1408021403158)
Finished the test on host x.x.x.x # Thu Aug 14 10:06:23 BRT 2014 (1408021583154)
Starting the test on host x.x.x.x # Thu Aug 14 10:07:53 BRT 2014 (1408021673181)
Finished the test on host x.x.x.x # Thu Aug 14 10:10:53 BRT 2014 (1408021853164)
Starting the test on host x.x.x.x # Thu Aug 14 10:25:23 BRT 2014 (1408022723204)
Finished the test on host x.x.x.x # Thu Aug 14 10:28:23 BRT 2014 (1408022903204)
Starting the test on host x.x.x.x # Thu Aug 14 10:33:13 BRT 2014 (1408023193224)
Finished the test on host x.x.x.x # Thu Aug 14 10:36:53 BRT 2014 (1408023413225)
I have a single instance of MongoDB 2.4.8 running on Windows Server 2012 R2. MongoDB is installed as a Windows Service. I have journalling enabled.
The MongoDB documentation suggests that the MongoDB service should just be shut down via the Windows Service Control Manager:
net stop MongoDB
When I did this recently, the following was logged and I ended up with a non-zero byte mongod.lock file on disk. (I used the --repair option to fix this but it turns out this probably wasn't necessary as I had journalling enabled.)
Thu Nov 21 11:08:12.011 [serviceShutdown] got SERVICE_CONTROL_STOP request from Windows Service Control Manager, will terminate after current cmd ends
Thu Nov 21 11:08:12.043 [serviceShutdown] now exiting
Thu Nov 21 11:08:12.043 dbexit:
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: going to close listening sockets...
Thu Nov 21 11:08:12.043 [serviceShutdown] closing listening socket: 1492
Thu Nov 21 11:08:12.043 [serviceShutdown] closing listening socket: 1500
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: going to flush diaglog...
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: going to close sockets...
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: waiting for fs preallocator...
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: lock for final commit...
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: final commit...
Thu Nov 21 11:08:12.043 [conn1333] end connection 127.0.0.1:51612 (18 connections now open)
Thu Nov 21 11:08:12.043 [conn1331] end connection 127.0.0.1:51610 (18 connections now open)
...snip...
Thu Nov 21 11:08:12.043 [conn1322] end connection 10.1.2.212:53303 (17 connections now open)
Thu Nov 21 11:08:12.043 [conn1337] end connection 127.0.0.1:51620 (18 connections now open)
Thu Nov 21 11:08:12.839 [serviceShutdown] shutdown: closing all files...
Thu Nov 21 11:08:14.683 [serviceShutdown] Progress: 5/163 3% (File Closing Progress)
Thu Nov 21 11:08:16.012 [serviceShutdown] Progress: 6/163 3% (File Closing Progress)
...snip...
Thu Nov 21 11:08:52.030 [serviceShutdown] Progress: 143/163 87% (File Closing Progress)
Thu Nov 21 11:08:54.092 [serviceShutdown] Progress: 153/163 93% (File Closing Progress)
Thu Nov 21 11:08:55.405 [serviceShutdown] closeAllFiles() finished
Thu Nov 21 11:08:55.405 [serviceShutdown] journalCleanup...
Thu Nov 21 11:08:55.405 [serviceShutdown] removeJournalFiles
Thu Nov 21 11:09:05.578 [DataFileSync] ERROR: Client::shutdown not called: DataFileSync
The last line is my main concern.
I'm also interested in how MongoDB is able to take longer to shut down than Windows normally allows for service shutdown? At what point is it safe to shut down the machine without checking the log file?