gstreamer webrtcbin TURN STURN only get typ host candidate? - webrtc

Test gstreamer webrtcbin android example, in local network everything is ok.But cross network, webrtc paused. ice send from android is all typ host.
Got ice server: candidate:1 1 UDP 2015363327 127.0.0.1 42258 typ host index: 0
Got ice server: candidate:2 1 TCP 1015021823 127.0.0.1 9 typ host tcptype active index: 0
Got ice server: candidate:3 1 TCP 1010827519 127.0.0.1 36241 typ host tcptype passive index: 0
Got ice server: candidate:4 1 UDP 2015363583 10.0.2.16 40513 typ host index: 0
Got ice server: candidate:5 1 TCP 1015022079 10.0.2.16 9 typ host tcptype active index: 0
Got ice server: candidate:6 1 TCP 1010827775 10.0.2.16 52791 typ host tcptype passive index: 0
Got ice server: candidate:7 1 UDP 2015363839 10.0.2.15 38413 typ host index: 0
Got ice server: candidate:8 1 TCP 1015022335 10.0.2.15 9 typ host tcptype active index: 0
Got ice server: candidate:9 1 TCP 1010828031 10.0.2.15 42225 typ host tcptype passive index: 0
#define STUN_SERVER " stun-server=stun://47.104.15.123:3478 "
#define TURN_SERVER " turn-server=turn://jianxi:jianxi#47.104.15.123:3478 "
webrtc->pipe =
gst_parse_launch ("webrtcbin bundle-policy=max-bundle name=sendrecv "
STUN_SERVER TURN_SERVER
if set GST_WEBRTC_ICE_TRANSPORT_POLICY_RELAY, android will not send any ice candidate.
sturn turn server is okay. Can not catch stun packet with wireshark.
g_signal_connect (webrtc->webrtcbin, "on-ice-candidate",
G_CALLBACK (send_ice_candidate_message), webrtc);
g_signal_connect (webrtc->webrtcbin, "notify::ice-gathering-state",
G_CALLBACK (on_ice_gathering_state_notify), NULL);
g_signal_connect (webrtc->webrtcbin, "notify::ice-connection-state",
G_CALLBACK (on_ice_gathering_state_notify), NULL);
gstreamer get signal notify:
static void
on_ice_gathering_state_notify (GstElement * webrtcbin, GParamSpec * pspec,
gpointer user_data)
{
GstWebRTCICEConnectionState ice_connect_state;
GstWebRTCICEGatheringState ice_gather_state;
gchar *stunser = NULL, *turnser = NULL;
const gchar *new_state = "unknown";
g_object_get (webrtcbin, "stun-server", &stunser, NULL);
if(stunser) {
gst_print("stun-server: %s\n", stunser);
g_free(stunser);
}
g_object_get (webrtcbin, "turn-server", &turnser, NULL);
if(turnser) {
gst_print("turn-server: %s\n", turnser);
g_free(turnser);
}
g_object_get (webrtcbin, "ice-gathering-state", &ice_gather_state, NULL);
g_object_get (webrtcbin, "ice-connection-state", &ice_connect_state, NULL);
switch (ice_gather_state) {
case GST_WEBRTC_ICE_GATHERING_STATE_NEW:
new_state = "new";
break;
case GST_WEBRTC_ICE_GATHERING_STATE_GATHERING:
new_state = "gathering";
break;
case GST_WEBRTC_ICE_GATHERING_STATE_COMPLETE:
new_state = "complete";
break;
}
gst_print ("ICE gathering state changed to %s, %d\n", new_state, ice_connect_state);
}
2022-11-23 11:35:50.239 1638-5461 GLib+stdout org.freedesktop.gstreamer.webrtc I stun-server: stun://47.104.15.123:3478
2022-11-23 11:35:50.239 1638-5461 GLib+stdout org.freedesktop.gstreamer.webrtc I turn-server: turn://jianxi:jianxi#47.104.15.123:3478
2022-11-23 11:35:50.239 1638-5461 GLib+stdout org.freedesktop.gstreamer.webrtc I ICE gathering state changed to complete, 4
ice end is 4 GST_WEBRTC_ICE_CONNECTION_STATE_FAILED.

In most cases, it means there are some issues with connecting to stun/turn server from your device. Either the host is unreachable via udp or there are issues with authentication.
The easiest way to test it is with trickle-ice page from your device's browser. Set address and creds of your stun/turn and check if there are some relay/srflx/prflx candidates.
If so, then it's a configuration issue on gstreamer-side.
If not, then try using tcpdump and inspect stun requests/responses. Maybe you're not getting the responses, or there are some error responses which might give you an idea of what's wrong.

Related

Website spying my address using WebRTC - what can they see?

Website I'm using connects from javascript to external WebRTC server to get information about me. They are getting response like this and sending selected information to their server.
RTCPeerConnectionIceEvent {isTrusted: true, candidate: RTCIceCandidate, type: 'icecandidate', target: RTCPeerConnection, currentTarget: RTCPeerConnection, …}
isTrusted: true
bubbles: false
cancelBubble: false
cancelable: false
candidate: RTCIceCandidate
address: "[edd1:73ea:ef2e:73eb:f08b:73ec:4f62:4888]"
candidate: "candidate:842163049 1 udp 1677732095 edd1:73ea:ef2e:73eb:f08b:73ec:4f62:4888 52280 typ srflx raddr :: rport 0 generation 0 ufrag +UaO network-cost 999"
component: "rtp"
foundation: "842163049"
port: 52280
priority: 1677732095
protocol: "udp"
relatedAddress: "[::]"
relatedPort: 0
sdpMLineIndex: 0
sdpMid: "1"
tcpType: null
type: "srflx"
usernameFragment: "+UaO"
[[Prototype]]: RTCIceCandidate
composed: false
Can anybody point me to a documentation or explain what information is encoded in address: "[edd1:73ea:ef2e:73eb:f08b:73ec:4f62:4888]" and what they can find out about me? It looks like IPv6 address but it is not.
Thanks
That section in the candidate line holds an IPv4 or IPv6 address. The address follows the priority 1677732095. Here are a few resources with detailed documentation:
https://webrtchacks.com/sdp-anatomy/
https://www.slideshare.net/saghul/ice-4414037 (slide 14)
https://tools.ietf.org/id/draft-ietf-ice-rfc5245bis-14.html

coturn STUN requests work locally, but not for remote connections

I've successfully made a TURN request to coturn server (https://github.com/coturn/coturn), but failed when executing a STUN request. If I try to STUN connect to coturn server from the same machine running the server using turnutils_stunclient myIP, the server responds with
RFC 5780 response 1
0: IPv4. Response origin: : IP1:3478
0: IPv4. Other addr: : IP2:3479
0: IPv4. UDP reflexive addr: IP1:36457
========================================
RFC 5780 response 2
0: IPv4. Response origin: : IP2:3479
0: IPv4. Other addr: : IP2:3479
0: IPv4. UDP reflexive addr: IP1:36457
========================================
RFC 5780 response 3
0: IPv4. Response origin: : IP2:3479
0: IPv4. Other addr: : IP2:3479
0: IPv4. UDP reflexive addr: IP1:36458
, which is great! To test STUN requests remotely, I've also installed coturn on my laptop. If I make the same request from my laptop, the stun server responds with only 1 response and hangs after that.
RFC 5780 response 1
0: IPv4. Response origin: : IP1:3478
0: IPv4. Other addr: : IP2:3479
0: IPv4. UDP reflexive addr: IP1:36457
There is no second and third message and the command line is blocked.
The problem is further confirmed when running javascript request:
function checkTURNServer(turnConfig, timeout){
return new Promise(function(resolve, reject){
setTimeout(function(){
if(promiseResolved) return;
resolve(false);
promiseResolved = true;
}, timeout || 5000);
var promiseResolved = false
, myPeerConnection = window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection //compatibility for firefox and chrome
, pc = new myPeerConnection({iceServers:[turnConfig]})
, noop = function(){};
pc.createDataChannel(""); //create a bogus data channel
pc.createOffer(function(sdp){
if(sdp.sdp.indexOf('typ relay') > -1){ // sometimes sdp contains the ice candidates...
promiseResolved = true;
resolve(true);
}
pc.setLocalDescription(sdp, noop, noop);
}, noop); // create offer and set local description
pc.onicecandidate = function(ice){ //listen for candidate events
if(promiseResolved || !ice || !ice.candidate || !ice.candidate.candidate || !(ice.candidate.candidate.indexOf('typ relay')>-1)) return;
promiseResolved = true;
resolve(true);
};
});
}
checkTURNServer({"url":"stun:IP1:3478"}).then(function(bool){
console.log('is TURN server active? ', bool? 'yes':'no'); // prints no!!
}).catch(console.error.bind(console));
What should I do to make STUN requests work? Can you point me in the right direction?
-----------------Additional info---------------------
I've tested just TURN functionality, and I was able connect:
checkTURNServer({"url":"turn:IP1:3478",username: 'mainuser',
credential: 'mainpassword' }).then(function(bool){
console.log('is TURN server active? ', bool? 'yes':'no'); // prints yes
}).catch(console.error.bind(console));
I've installed coturn and configured it as a service. This is the contents of my /etc/systemd/system/coturn.service file:
[Unit]
Description=turnserver Service
After=network.target
[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/turnserver -c /usr/local/etc/turnserver.conf
Restart=on-abort
[Install]
WantedBy=multi-user.target
When I run systemctl start coturn, service starts normally.
Contents of /usr/local/etc/turnserver.conf
listening-ip=IP1
listening-ip=IP2
lt-cred-mech
user=mainuser:mainpassword
realm=mydomain.com
max-bps=128000
cert=/etc/letsencrypt/live/mydomain.com/cert.pem
pkey=/etc/letsencrypt/live/mydomain.com/privkey.pem
result of iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N FORWARD_IN_ZONES
-N FORWARD_IN_ZONES_SOURCE
-N FORWARD_OUT_ZONES
-N FORWARD_OUT_ZONES_SOURCE
-N FORWARD_direct
-N FWDI_iredmail
-N FWDI_iredmail_allow
-N FWDI_iredmail_deny
-N FWDI_iredmail_log
-N FWDO_iredmail
-N FWDO_iredmail_allow
-N FWDO_iredmail_deny
-N FWDO_iredmail_log
-N INPUT_ZONES
-N INPUT_ZONES_SOURCE
-N INPUT_direct
-N IN_iredmail
-N IN_iredmail_allow
-N IN_iredmail_deny
-N IN_iredmail_log
-N OUTPUT_direct

SSL certificate verification on ESP8266 Wemos D1 Mini with MQTT broker

I have a raspberry pi 3 with raspbian stretch as its operating system. I have installed and fully configured a MQTT broker on the raspberry pi following this tutorial: https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-the-mosquitto-mqtt-messaging-broker-on-ubuntu-16-04
Everything works fine and well on the broker's side. The certificates get renewed after 60 days and you can only connect to port 1883 via the localhost and the other ports (8883 and 8083) are open but can only be accessed using TLS version 1.2 and for the latter also using websockets. Below you can find the code of my configuration of mosquitto (/etc/mosquitto/conf.d/default.conf).
allow_anonymous false
password_file /etc/mosquitto/passwd
listener 1883 localhost
listener 8883
certfile /etc/letsencrypt/live/home.kamidesigns.be/cert.pem
cafile /etc/letsencrypt/live/home.kamidesigns.be/chain.pem
keyfile /etc/letsencrypt/live/home.kamidesigns.be/privkey.pem
tls_version tlsv1.2
listener 8083
protocol websockets
certfile /etc/letsencrypt/live/home.kamidesigns.be/cert.pem
cafile /etc/letsencrypt/live/home.kamidesigns.be/chain.pem
keyfile /etc/letsencrypt/live/home.kamidesigns.be/privkey.pem
tls_version tlsv1.2
I also bought a ESP8266 Wemos D1 Mini to connect to this broker in a secure way. I used the pubsubclient library from this link: https: //github.com/knolleary/pubsubclient for my MQTT client.
I use the master branch of this link: https://github.com/esp8266/Arduino for my secure SSL connection. Below you see the code I used for programming my Wemos D1 Mini
#include <ESP8266WiFi.h>
#include <PubSubClient.h>
#include <time.h>
void callback(char* topic, byte* payload, unsigned int length) {
Serial.print("Message arrived [");
Serial.print(topic);
Serial.print("] ");
for (int i = 0; i < length; i++) {
Serial.print((char)payload[i]);
}
Serial.println();
}
const char* ssid = "ssid";
const char* password = "wifipassword";
const char* host = "home.kamidesigns.be";
const int port = 8883;
WiFiClientSecure espClient;
PubSubClient client(host, port, callback, espClient);
long lastMsg = 0;
char msg[50];
int value = 0;
void setup() {
Serial.begin(115200);
Serial.println();
Serial.print("connecting to ");
Serial.println(ssid);
WiFi.begin(ssid, password);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());
// Synchronize time useing SNTP. This is necessary to verify that
// the TLS certificates offered by the server are currently valid.
Serial.print("Setting time using SNTP");
configTime(8 * 3600, 0, "pool.ntp.org", "time.nist.gov");
time_t now = time(nullptr);
while (now < 1000) {
delay(500);
Serial.print(".");
now = time(nullptr);
}
Serial.println("");
struct tm timeinfo;
gmtime_r(&now, &timeinfo);
Serial.print("Current time: ");
Serial.print(asctime(&timeinfo));
}
void reconnect() {
// Loop until we're reconnected
while (!client.connected()) {
Serial.print("Attempting MQTT connection...");
// Attempt to connect
if (client.connect("ESP8266LightController","username","password")) {
Serial.println("connected");
// Once connected, publish an announcement...
client.publish("outTopic", "hello world");
// ... and resubscribe
client.subscribe("inTopic");
} else {
Serial.print("failed, rc=");
Serial.print(client.state());
Serial.println(" try again in 5 seconds");
// Wait 5 seconds before retrying
delay(5000);
}
}
}
When I start my Wemos D1, the serial monitor says:
connecting to ssid
..
WiFi connected
IP address:
192.168.0.213
Setting time using SNTP.
Current time: Sat Oct 14 02:26:25 2017
Attempting MQTT connection...connected
This is good and it is exactly what I wanted but I'm confused by how my Wemos D1 is able to connect to port 8883 without it verifying the certificate chain of the server? Remember that I never uploaded a certificate to the Wemos D1 or implemented a certificate into the code, and still it can connect.
One of 2 options
The WiFiClientSecure includes a list of public CA certs and is verifying your certificate against this list
The WiFiClientSecure defaults to not verifying remote certs by default.
Looking at this issue it looks like option 2 is most likely as it implies you have to verify the cert yourself after the connection.

Kurento Hello World Stuck after receiving candidates

I am trying to setup a Kurento media server behind an nginx proxy & testing with the Kurento-hello-world example. The TURN server is in place & Kurento is up.
I added the TURN url in file /etc/kurento/modules/kurento/WebRtcEndpoint.conf.ini as explained here
turnURL=kurento:kurento#193.147.XXX.XXX:3478
I opened the specified ports :
3478 TCP & UDP
49152-65535 UDP
EDIT : I notice TURN is announcing a remote HEAD IP that seems to be in my network, but is not linked to my project and never specified in configs, as seen in the browser console, I receive a candidate 2 with the unknown external IP and a candidate 3 with good external IP but wonder if the browser can be stocked trying to connect to a bad one. Is it possible to avoid TURN propose a specific address ?
Locally, I can see (netstat -tulpn) the candidates UDP ports allocted on both kurento & TURN machines. The video input that should come from the server never appears, meaning the Connection is never achieved ?
TURN Server :
handle_udp_packet: New UDP endpoint: local addr 192.168.LO.CAL:3478, remote addr 130.206.UNK.KNO:54384
realm <x> user <>: incoming packet OLD BINDING processed, success
realm <x> user <kurento>: incoming packet OLD BINDING processed, success
realm <x> user <kurento>: incoming packet OLD BINDING processed, success
realm <x> user <>: incoming packet OLD BINDING processed, success
realm <x> user <>: incoming packet OLD BINDING processed, success
realm <x> user <kurento>: incoming packet OLD BINDING processed, success
closed (2nd stage), user <> realm <x> origin <>, local 192.168.LO.CAL:3478, remote **130.206.UNK.KNO**:54384, reason: allocation watchdog determined stale session state
Brower Hello-World Console :
WebRTC loopback starting
Use freeice
...
Created SDP offer
Local description set
...
onOffer
Got MediaPipeline
...
Local candidate:
{}
Got WebRtcEndpoint
Got FaceOverlayFilter
Connecting...
SDP answer obtained. Processing...
SDP answer received, setting remote description
SDP answer received, setting remote description
Remote candidate:
{
__module__: 'kurento'
,
__type__: 'IceCandidate'
,
candidate: 'candidate:1 1 UDP 2013266431 192.168.LO.CAL 53311 typ host'
,
sdpMLineIndex: 0
,
sdpMid: 'audio'
}
ICE candidate received
Remote candidate:
{
__module__: 'kurento'
,
__type__: 'IceCandidate'
,
candidate: 'candidate:1 1 UDP 2013266431 192.168.LO.CAL 53311 typ host'
,
sdpMLineIndex: 1
,
sdpMid: 'video'
}
ICE candidate received
Remote URL:
'blob:http%3A//localhost%3A8080/7b1cfb2c-d8bd-4e74-9a98-990ff35ac3fe'
Remote candidate:
{
__module__: 'kurento'
,
__type__: 'IceCandidate'
,
candidate: 'candidate:1 2 UDP 2013266430 192.168.LO.CAL 54384 typ host'
,
sdpMLineIndex: 0
,
sdpMid: 'audio'
}
ICE candidate received
Remote candidate:
{
__module__: 'kurento'
,
__type__: 'IceCandidate'
,
candidate: 'candidate:1 2 UDP 2013266430 192.168.LO.CAL 54384 typ host'
,
sdpMLineIndex: 1
,
sdpMid: 'video'
}
ICE candidate received
Loopback established
Remote candidate:
{
__module__: 'kurento'
,
__type__: 'IceCandidate'
,
candidate: 'candidate:2 1 UDP 1677721855 130.206.UNK.KNO 53311 typ srflx raddr 192.168.LO.CAL rport 53311'
,
sdpMLineIndex: 0
,
sdpMid: 'audio'
}
ICE candidate received
Remote candidate:
{
__module__: 'kurento'
,
__type__: 'IceCandidate'
,
candidate: 'candidate:2 1 UDP 1677721855 130.206.UNK.KNO 53311 typ srflx raddr 192.168.LO.CAL rport 53311'
,
sdpMLineIndex: 1
,
sdpMid: 'video'
}
ICE candidate received
Remote candidate:
{
__module__: 'kurento'
,
__type__: 'IceCandidate'
,
candidate: 'candidate:3 1 UDP 1006633215 130.206.REM.OTE 63499 typ relay raddr 192.168.LO.CAL rport 53311'
,
sdpMLineIndex: 0
,
sdpMid: 'audio'
}
ICE candidate received
Remote candidate:
{
__module__: 'kurento'
,
__type__: 'IceCandidate'
,
candidate: 'candidate:3 1 UDP 1006633215 130.206.REM.OTE 63499 typ relay raddr 192.168.LOC.AL rport 53311'
,
sdpMLineIndex: 1
,
sdpMid: 'video'
}
ICE candidate received
And the kurento log (sorry) :
pointImpl.cpp:281 WebRtcEndpointImpl() stun port 3478
pointImpl.cpp:285 WebRtcEndpointImpl() stun address 130.206.REM.OTE
pointImpl.cpp:294 WebRtcEndpointImpl() turn info:
...
Transport.cpp:482 processMessage() Message: >{"id":19,"jsonrpc":"2.0","method":"invoke","params":{"object":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","operation":"gatherCandidates","sessionId":"f3b4f17e-d7e1-44d6-aec5-e0106ce37c50"}}
EventHandler.cpp:52 sendEvent() Sending event: {"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:1 1 UDP 2013266431 192.168.LO.CAL 58764 typ host","sdpMLineIndex":0,"sdpMid":"audio"},"source":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","tags":[],"timestamp":"1449959528","type":"OnIceCandidate"},"object":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
-> f3b4f17e-d7e1-44d6-aec5-e0106ce37c50
KurentoEventHandler EventHandler.cpp:52 sendEvent() Sending event: {"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:1 1 UDP 2013266431 192.168.LO.CAL 58764 typ host","sdpMLineIndex":1,"sdpMid":"video"},"source":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","tags":[],"timestamp":"1449959528","type":"OnIceCandidate"},"object":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
-> f3b4f17e-d7e1-44d6-aec5-e0106ce37c50
KurentoEventHandler EventHandler.cpp:52 sendEvent() Sending event: {"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:1 2 UDP 2013266430 192.168.LO.CAL 36158 typ host","sdpMLineIndex":0,"sdpMid":"audio"},"source":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","tags":[],"timestamp":"1449959528","type":"OnIceCandidate"},"object":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
-> f3b4f17e-d7e1-44d6-aec5-e0106ce37c50
KurentoEventHandler EventHandler.cpp:52 sendEvent() Sending event: {"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:1 2 UDP 2013266430 192.168.LO.CAL 36158 typ host","sdpMLineIndex":1,"sdpMid":"video"},"source":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","tags":[],"timestamp":"1449959528","type":"OnIceCandidate"},"object":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
-> f3b4f17e-d7e1-44d6-aec5-e0106ce37c50
Transport.cpp:484 processMessage() Response: >{"id":19,"jsonrpc":"2.0","result":{"sessionId":"f3b4f17e-d7e1-44d6-aec5-e0106ce37c50","value":null}}
Transport.cpp:482 processMessage() Message: >{"id":20,"jsonrpc":"2.0","method":"invoke","params":{"object":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/d4e4e54b-1610-4b0c-93e7-5f46558c7a40_kurento.FaceOverlayFilter","operation":"setOverlayedImage","operationParams":{"heightPercent":1.6000000000000001,"offsetXPercent":-0.34999999999999998,"offsetYPercent":-1.2,"uri":"https://localhost:8080/img/mario-wings.png","widthPercent":1.6000000000000001},"sessionId":"f3b4f17e-d7e1-44d6-aec5-e0106ce37c50"}}
Transport.cpp:484 processMessage() Response: >{"id":20,"jsonrpc":"2.0","result":{"sessionId":"f3b4f17e-d7e1-44d6-aec5-e0106ce37c50","value":null}}
Transport.cpp:482 processMessage() Message: >{"id":21,"jsonrpc":"2.0","method":"invoke","params":{"object":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","operation":"connect","operationParams":{"sink":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/d4e4e54b-1610-4b0c-93e7-5f46558c7a40_kurento.FaceOverlayFilter"},"sessionId":"f3b4f17e-d7e1-44d6-aec5-e0106ce37c50"}}
ementImpl.cpp:655 connect() Connecting 235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint -> 235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/d4e4e54b-1610-4b0c-93e7-5f46558c7a40_kurento.FaceOverlayFilter params AUDIO
ementImpl.cpp:655 connect() Connecting 235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint -> 235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/d4e4e54b-1610-4b0c-93e7-5f46558c7a40_kurento.FaceOverlayFilter params VIDEO
ementImpl.cpp:655 connect() Connecting 235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint -> 235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/d4e4e54b-1610-4b0c-93e7-5f46558c7a40_kurento.FaceOverlayFilter params DATA
Transport.cpp:484 processMessage() Response: >{"id":21,"jsonrpc":"2.0","result":{"sessionId":"f3b4f17e-d7e1-44d6-aec5-e0106ce37c50","value":null}}
Transport.cpp:482 processMessage() Message: >{"id":22,"jsonrpc":"2.0","method":"invoke","params":{"object":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/d4e4e54b-1610-4b0c-93e7-5f46558c7a40_kurento.FaceOverlayFilter","operation":"connect","operationParams":{"sink":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint"},"sessionId":"f3b4f17e-d7e1-44d6-aec5-e0106ce37c50"}}
ementImpl.cpp:655 connect() Connecting 235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/d4e4e54b-1610-4b0c-93e7-5f46558c7a40_kurento.FaceOverlayFilter -> 235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint params AUDIO
ementImpl.cpp:655 connect() Connecting 235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/d4e4e54b-1610-4b0c-93e7-5f46558c7a40_kurento.FaceOverlayFilter -> 235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint params VIDEO
ementImpl.cpp:655 connect() Connecting 235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/d4e4e54b-1610-4b0c-93e7-5f46558c7a40_kurento.FaceOverlayFilter -> 235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint params DATA
EventHandler.cpp:52 sendEvent() Sending event: {"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:2 1 UDP 1677721855 130.206.UNK.KNO 58764 typ srflx raddr 192.168.LO.CAL rport 58764","sdpMLineIndex":0,"sdpMid":"audio"},"source":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","tags":[],"timestamp":"1449959528","type":"OnIceCandidate"},"object":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
-> f3b4f17e-d7e1-44d6-aec5-e0106ce37c50
EventHandler.cpp:52 sendEvent() Sending event: {"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:2 1 UDP 1677721855 130.206.UNK.KNO 58764 typ srflx raddr 192.168.LO.CAL rport 58764","sdpMLineIndex":1,"sdpMid":"video"},"source":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","tags":[],"timestamp":"1449959528","type":"OnIceCandidate"},"object":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
-> f3b4f17e-d7e1-44d6-aec5-e0106ce37c50
Transport.cpp:484 processMessage() Response: >{"id":22,"jsonrpc":"2.0","result":{"sessionId":"f3b4f17e-d7e1-44d6-aec5-e0106ce37c50","value":null}}
EventHandler.cpp:52 sendEvent() Sending event: {"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:3 1 UDP 1006633215 130.206.REM.OTE 52131 typ relay raddr 192.168.LO.CAL rport 58764","sdpMLineIndex":0,"sdpMid":"audio"},"source":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","tags":[],"timestamp":"1449959528","type":"OnIceCandidate"},"object":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
-> f3b4f17e-d7e1-44d6-aec5-e0106ce37c50
EventHandler.cpp:52 sendEvent() Sending event: {"jsonrpc":"2.0","method":"onEvent","params":{"value":{"data":{"candidate":{"__module__":"kurento","__type__":"IceCandidate","candidate":"candidate:3 1 UDP 1006633215 130.206.REM.OTE52131 typ relay raddr 192.168.LO.CAL rport 58764","sdpMLineIndex":1,"sdpMid":"video"},"source":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","tags":[],"timestamp":"1449959528","type":"OnIceCandidate"},"object":"235a7f0a-87c0-4b8d-a726-e91b7095ea7b_kurento.MediaPipeline/4d01d709-1471-4fa6-b889-b3a79cb4e02c_kurento.WebRtcEndpoint","type":"OnIceCandidate"}}}
-> f3b4f17e-d7e1-44d6-aec5-e0106ce37c50
Transport.cpp:543 closeHandler() Connection closed
Transport.cpp:504 openHandler() Client connected from http://localhost:8080
Thanks !
EDIT : installed packages/version
gstreamer1.5-libav:amd64/1.5.2.1~20150901123759.34.g07a7b16.trusty
gstreamer1.5-nice:amd64/0.1.7.1~20151125151103.10.ge060eb5.trusty
gstreamer1.5-plugins-bad:amd64/1.5.2.1~20150901123827.61.gced9e06.trusty
gstreamer1.5-plugins-base:amd64/1.7.0.1~20151125150805.140.g2b445d5.trusty
gstreamer1.5-plugins-good:amd64/.7.0.1~20151125150841.141.g0708286.trusty
gstreamer1.5-plugins-ugly:amd64/1.7.0.1~20151126085656.24.g9ec26a4.trusty
gstreamer1.5-pulseaudio:amd64/1.7.0.1~20151125150841.141.g0708286.trusty
gstreamer1.5-x:amd64/1.7.0.1~20151125150805.140.g2b445d5.trusty
kms-core-6.0/6.2.0.trusty
kms-elements-6.0/6.2.0.trusty
kms-filters-6.0/6.2.0.trusty
kms-jsonrpc-1.0/1.0.1.trusty
kmsjsoncpp/1.6.3~20151125151041.38.g263929e.trusty
kurento-media-server-6.0/6.1.0.trusty
libgstreamer-plugins-bad1.5-0:amd64/1.5.2.1~20150901123827.61.gced9e06.trusty
libgstreamer-plugins-base1.5-0:amd64/1.7.0.1~20151125150805.140.g2b445d5.trusty
libgstreamer1.5-0:amd64/1.7.0.1~20151125150753.298.g6d22bfb.trusty
libnice10:amd64/0.1.7.1~20151125151103.10.ge060eb5.trusty
openwebrtc-gst-plugins/0.10.0~20151125150950.100.g61cc54b.trusty
Hello Jean-Baptiste Heren , This is the issue of dependencies. So i
suggest you to please installed all of your dependencies correctly or
upgarde your dist first and than install Kurento-media-server 6.0
after that you will be able to resloved all of these issues in one go
for same related issue with commands please follow the link answer:-
And also install openJdk7
Node Tutorial one to Many has no loading the remote server Stream Spinner moving endless
Thanks

Varnish and SSL with Pound

I've set up my Varnish server as follows:
backend web1 {.host = "XXX.XXX.XXX.XXX"; .port = "80";}
backend web2 {.host = "XXX.XXX.XXX.XXX"; .port = "80";}
backend web3 {.host = "XXX.XXX.XXX.XXX"; .port = "80";}
backend web1_ssl {.host = "XXX.XXX.XXX.XXX"; .port = "443";}
backend web2_ssl {.host = "XXX.XXX.XXX.XXX"; .port = "443";}
backend web3_ssl {.host = "XXX.XXX.XXX.XXX"; .port = "443";}
director default_director round-robin {
{ .backend = web1; }
{ .backend = web2; }
{ .backend = web3; }
}
director ssl_director round-robin {
{ .backend = web1_ssl; }
{ .backend = web2_ssl; }
{ .backend = web3_ssl; }
}
# Respond to incoming requests.
sub vcl_recv {
# Set the director to cycle between web servers.
set req.grace = 120s;
if (req.http.X-Forwarded-Proto == "https" ) {
set req.http.X-Forwarded-Port = "443";
set req.backend = ssl_director;
} else {
set req.http.X-Forwarded-Port = "80";
set req.http.X-Forwarded-Proto = "http";
set req.backend = default_director;
}
...
}
This works perfectly if I hit my IP address (without SSL) in the browser, but if I enable Pound (config below):
ListenHTTPS
Address XXX.XXX.XXX.XXX #Local IP of the VarnishWebServer
Port 443
Cert "/etc/apache2/ssl/apache.pem"
AddHeader "X-Forwarded-Proto: https"
HeadRemove "X-Forwarded-Proto"
Service
BackEnd
Address 127.0.0.1
Port 80
End
End
End
I get a 503 everyime I try to hit the local IP address (from varnishlog -0):
11 RxURL c /favicon.ico
11 RxProtocol c HTTP/1.1
11 RxHeader c Host: XXX.XXX.XXX (Varnish Server IP Address)
11 RxHeader c Connection: keep-alive
11 RxHeader c Accept: */*
11 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36
11 RxHeader c Accept-Encoding: gzip,deflate,sdch
11 RxHeader c Accept-Language: en-US,en;q=0.8
11 RxHeader c X-Forwarded-Proto: https
11 RxHeader c X-SSL-cipher: DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
11 RxHeader c X-Forwarded-For: XXX.XXX.XXX.XXX (My Local machine IP)
11 VCL_call c recv lookup
11 VCL_call c hash
11 Hash c /favicon.ico
11 Hash c 198.61.252.81
11 VCL_return c hash
11 VCL_call c miss fetch
11 Backend c 14 ssl_director web2_ssl
11 FetchError c http read error: -1 0 (Success)
11 VCL_call c error deliver
11 VCL_call c deliver deliver
11 TxProtocol c HTTP/1.1
11 TxStatus c 503
11 TxResponse c Service Unavailable
11 TxHeader c Server: Varnish
...
11 ReqEnd c 1175742305 1391779282.930887222 1391779282.934647560 0.000097752 0.003678322 0.000082016
11 SessionClose c error
I looked at my http listeners and I see this:
root#machine:/etc/apache2/ssl# lsof -i -n|grep http
pound 7947 www-data 5u IPv4 63264 0t0 TCP XXX.XXX.XXX.XXXX:https (LISTEN)
pound 7948 www-data 5u IPv4 63264 0t0 TCP XXX.XXX.XXX.XXXX:https (LISTEN)
varnishd 8333 nobody 7u IPv4 64977 0t0 TCP *:http (LISTEN)
varnishd 8333 nobody 8u IPv6 64978 0t0 TCP *:http (LISTEN)
varnishd 8333 nobody 13u IPv4 65029 0t0 TCP XXX.XXX.XXX.XXXX:37493- >YYYY.YYYY.YYYY.YYYY3:http (CLOSE_WAIT)
apache2 19433 root 3u IPv4 31020 0t0 TCP *:http-alt (LISTEN)
apache2 19438 www-data 3u IPv4 31020 0t0 TCP *:http-alt (LISTEN)
apache2 19439 www-data 3u IPv4 31020 0t0 TCP *:http-alt (LISTEN)
pound 19669 www-data 5u IPv4 31265 0t0 TCP 127.0.0.1:https (LISTEN)
pound 19670 www-data 5u IPv4 31265 0t0 TCP 127.0.0.1:https (LISTEN)
Where XXX.XXX.XXX.XXX is the varnish's WebServer's internal IP address, and YYYY.YYYY.YYYY.YYY is the IP address of one of the backend system defined in the VCL.
Any idea why I keep getting 503s?
UPDATE
As noted Varnish doesn't support SSL, so using Pound can transfer the traffic from 443 to 80, but when it's finished - it can't use port 443 (ssl_diretector) to serve the traffic. Removing the ssl_director and making default_director the primary, worked perfectly.
Varnish does not support HTTPS for its backend requests - any communication between Varnish and Apache must be plain HTTP.
What I found works best is to configure Apache to speak plain HTTP on port 443. This allows Apache to generate correct URLs, such as when it needs to redirect the browser.
Here's how you might configure it:
# Listen on port 443, but speak plain HTTP
Listen X.X.X.X:443 http
# Setting HTTPS=on is helpful for ensuring correct behavior of scripting
# languages such as PHP
SetEnvIf X-Forwarded-Proto "^https$" HTTPS=on
<VirtualHost X.X.X.X:443>
# Specifying "https://" in the ServerName ensures that whenever
# Apache generates a URL, it uses "https://your.site.com/" instead
# of "http://your.site.com:443/"
ServerName https://your.site.com
</VirtualHost>
You will of course need to remove any mod_ssl directives from your Apache configuration.