Media not flowing in at connected Endpoints

[Rene Bernhardt]

I have two webrtcEndpoinst connected in both direction for mediatype "AUDIO".

When I request the Sinkconnections and Sourceconnections via getSourceConnections and getSinkConnections I can see that it is set up correctly.

But nevertheless the media is not flowing in on the second webrtcEndpoint. ( requested via isMediaFlowingIn and isMediaFlowingOut )

The second endpoint is connected to another media server and therefore generateOffer was used and not ( as usual ) the processOffer when getting an offer from the browser.

The first endpoint is connected to the browser , media is flowing in and out at this endpoint. By the help of the "getStats" I can see that the second endpoint is receiving data from its outgoing webrtc connection but it is not sending anything.

That is because it does not get anything forwarded from the first endpoint. ....media is NOT flowing in at the second endpoint.

In the other direction it is working as expected. The second endpoint forwards the audio to the first endpoint and a can hear it via the peerconnection from the browser. But the audio which is sent by the browser does not make it through to the second endpoint.

What could be wrong ?

[Ivan Gracia]

No clue. Can you show the connecting code? Also, what KMS version are you using?

Ivan Gracia

--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.
To post to this group, send email to kur...@googlegroups.com.
Visit this group at https://groups.google.com/group/kurento.
To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/33423f3b-f1d0-4d7d-85d4-826c3bb8c707%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Georgy Georgiev]

I have the same issue. I am trying to connect an RtpEndpoint to a WebRtcEndpoint. Their status is "CONNECTED" while the media status is NOT. 

My signalling code works like this:

1) Create a pipeline

2) Create an RtpEndpoint

3) Create an WebRtcEndpoint

4) webrtcEndpoint.on( 'IceCandidateFound' ... => send candidates to the browser client.

5) RtpEndpoint.connect(WebRtcEndpoint ...

6) RtpEndpoint.processOffer(...

7) WebRtcEndpoint.generateOffer( ...

8) Process the offer in the browser client and send an answer.

9) WebRtcEndpoint.processAnswer( ...

10) WebRtcEndpoint.gatherCandidates( ...

The input for the RtpEndpoint is the following:

`gst-launch-1.0 -v v4l2src videotestsrc ! queue ! videorate ! videoconvert ! videoscale ! video/x-raw,width=640,height=480,framerate=30/1 ! x264enc tune=zerolatency ! rtph264pay pt=96 ! udpsink host=<server port> port=<some port>`

I can receive it with gstreamer on the the target machine/server with:

`gst-launch-1.0 udpsrc port=<port as above> ! application/x-rtp,framerate=30/1 ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink`

I am using NodeJS as a signaling server. Kurento is run inside a Docker container with Stun/Turn configured (I've tried a standalone installation too). 

The output I get from the signaling server is:

`==> Signalling server started on https://localhost:8443/cam
==> Socket connection created.
Connection null closed
==> Socket connection created.
==> ID:  webrtcStart
==> Stream negotiation start.
==> Rtp: CONNECTED
==> ID:  webrtcAnswer
==> ID:  webrtcIceCandidate
Sending candidate
==> ID:  webrtcIceCandidate
Sending candidate
==> MediaSessionStarted
==> IceComponentStateChange:  GATHERING
==> IceComponentStateChange:  GATHERING
==> IceComponentStateChange:  CONNECTED
==> IceComponentStateChange:  READY
==> IceComponentStateChange:  CONNECTING
==> IceComponentStateChange:  CONNECTED
==> WebRTC: CONNECTED
==> IceComponentStateChange:  READY
==> Media: DISCONNECTED
==> WebRTC: CONNECTED
==> IceComponentStateChange:  CONNECTED
==> IceGatheringDone
==> IceComponentStateChange:  READY
==> WebRTC: CONNECTED`

In the browser (Firefox and Chrome) I get something like:

This appears to be <browser> adapter.js:34:5
==> Signaling: A web socket has opened.  main.js:116:7
==> Signaling: A WebRTC procedure has started.  main.js:90:5
==> ID: sdpOffer  main.js:113:5
==> Signaling: An SDP answer is being sent.  main.js:67:5
==> ID: iceCandidate  main.js:113:5

Remote ICE candidate received Object { candidate: "candidate:2 2 TCP 1019217150 fe80::…", sdpMid: "video0", sdpMLineIndex: 1, __module__: "kurento", __type__: "IceCandidate" }  kurento-utils.js:251:9

==> ID: iceCandidate  main.js:113:5
Remote ICE candidate received Object { candidate: "candidate:3 2 TCP 1015022846 fe80::…", sdpMid: "audio0", sdpMLineIndex: 0, __module__: "kurento", __type__: "IceCandidate" }  kurento-utils.js:251:9
...

On Thursday, December 8, 2016 at 6:00:51 PM UTC+2, igracia wrote:

No clue. Can you show the connecting code? Also, what KMS version are you using?

Ivan Gracia

On Mon, Dec 5, 2016 at 3:37 PM, Rene Bernhardt <rbee...@gmail.com> wrote:

I have two webrtcEndpoinst connected in both direction for mediatype "AUDIO".

When I request the Sinkconnections and Sourceconnections via getSourceConnections and getSinkConnections I can see that it is set up correctly.

But nevertheless the media is not flowing in on the second webrtcEndpoint. ( requested via isMediaFlowingIn and isMediaFlowingOut )

The second endpoint is connected to another media server and therefore generateOffer was used and not ( as usual ) the processOffer when getting an offer from the browser.

The first endpoint is connected to the browser , media is flowing in and out at this endpoint. By the help of the "getStats" I can see that the second endpoint is receiving data from its outgoing webrtc connection but it is not sending anything.

That is because it does not get anything forwarded from the first endpoint. ....media is NOT flowing in at the second endpoint.

In the other direction it is working as expected. The second endpoint forwards the audio to the first endpoint and a can hear it via the peerconnection from the browser. But the audio which is sent by the browser does not make it through to the second endpoint.

What could be wrong ?

--
You received this message because you are subscribed to the Google Groups "kurento" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.

[Georgy Georgiev]

Managed to resolve the problem. It had to do with Docker. In my case, Kurento is run inside a docker container. OnceI ran Kurento as a standalone server and then gave the IP of the kurento host and the port specified by the processed rtp sdp offer to the streaming source (gstreamer in my case), it worked. I am still struggling with Docker. I have tried forwarding a range of ports, which I specify also in the BaseRtpEndpoint.conf.ini.