TCP ICE not working with Wowza transcoder

[dgunay]

NOTE: I feel like the root cause might be because Pion doesn't support active TCP-ICE yet, but below is some more info about my situation.

(maybe this is better off in pion/ice, not sure. If it is, let me know).

Your environment.

• Version: 3.1.2
• Browser: N/A
• Other Information:

I'm creating a Go application which takes an incoming WebRTC connection and forwards it out to a Wowza transcoder hosted in Wowza Streaming Cloud.

The incoming peerconnection and handshake go smoothly. I then read and write the bytes from each track over into TrackLocalStaticRTPs. I instantiate a new peerconnection with these tracks, and then attempt to connect to the Wowza transcoder.

Their hosted transcoders only support ICE over TCP. This has not been a problem for me in the browser and happens more or less without any effort or weird off-tutorial configuration, but when trying to negotiate ICE using Pion this has totally stumped me.

What did you do?

Here is an example candidate their signaling endpoint sends me back:

{Candidate:candidate:0 1 TCP 50 35.236.28.45 1935 typ host generation 0 SDPMid:0xc0000fd8f0 SDPMLineIndex:0xc00028f840 UsernameFragment:<nil>}

They always only send back one candidate, which I'm pretty sure is the IP address of the transcoder instance itself. I add that ICE candidate, and that kicks off the checking phase of ICE connection (TRACE level logs below):

INFO[0162] Wowza RTC ice connection state changed to checking 
ice TRACE: 23:46:38.009476 agent.go:593: pinging all candidates
ice WARNING: 2021/10/05 23:46:38 pingAllCandidates called with no candidate pairs. Connection is not possible yet.
INFO[0162] awaiting connection...                       
ice TRACE: 23:46:38.009509 agent.go:593: pinging all candidates
ice TRACE: 23:46:38.009536 agent.go:953: ping STUN from tcp4 host 192.168.1.209:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.009557 agent.go:953: ping STUN from tcp4 host 172.18.0.1:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.009574 agent.go:953: ping STUN from tcp4 host 172.17.0.1:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.009591 agent.go:953: ping STUN from tcp4 host 172.19.0.1:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.210154 agent.go:593: pinging all candidates
ice TRACE: 23:46:38.210195 agent.go:953: ping STUN from tcp4 host 192.168.1.209:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.210220 agent.go:953: ping STUN from tcp4 host 172.18.0.1:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.210246 agent.go:953: ping STUN from tcp4 host 172.17.0.1:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.210263 agent.go:953: ping STUN from tcp4 host 172.19.0.1:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.410853 agent.go:593: pinging all candidates
ice TRACE: 23:46:38.410876 agent.go:953: ping STUN from tcp4 host 192.168.1.209:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.410888 agent.go:953: ping STUN from tcp4 host 172.18.0.1:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.410897 agent.go:953: ping STUN from tcp4 host 172.17.0.1:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.410908 agent.go:953: ping STUN from tcp4 host 172.19.0.1:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.611276 agent.go:593: pinging all candidates
ice TRACE: 23:46:38.611316 agent.go:953: ping STUN from tcp4 host 192.168.1.209:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.611332 agent.go:953: ping STUN from tcp4 host 172.18.0.1:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.611345 agent.go:953: ping STUN from tcp4 host 172.17.0.1:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.611354 agent.go:953: ping STUN from tcp4 host 172.19.0.1:3478 to tcp4 host 35.236.28.45:1935
ice WARNING: 2021/10/05 23:46:38 failed to send packet: io: read/write on closed pipe
ice TRACE: 23:46:38.787775 selection.go:173: checking keepalive
...

So it just keeps trying all the local ICE candidates against Wowza's and fails. Eventually it gives up and the connection state changes to failed.

I'm not sure what the read/write on closed pipe part is supposed to mean. I also am not sure why the STUN part shows up even when I remove the ICE server from the configuration. I currently suspect this is because the example is for passive ICE TCP, when the other end expects me to do active ICE TCP.

I tried to follow the ice-tcp example, but it doesn't seem to be helping.
Here is a few of my bits of configuration:

Creating the peerconnection:

// Creates a peerconnection which only uses TCP over ICE
func NewPeerConnectionWithTCPTransport(port int) (*webrtc.PeerConnection, error) {
	settingEngine := webrtc.SettingEngine{}

	// Enable support only for TCP ICE candidates.
	settingEngine.SetNetworkTypes([]webrtc.NetworkType{
		webrtc.NetworkTypeTCP4,
		// webrtc.NetworkTypeTCP6,
	})

	var tcpListener net.Listener
	tcpListener, err := net.ListenTCP("tcp", &net.TCPAddr{
		IP:   net.IP{0, 0, 0, 0},
		Port: port,
	})
	if err != nil {
		return nil, fmt.Errorf("listening on TCP: %w", err)
	}
	logrus.Infof("Listening for ICE TCP at %s\n", tcpListener.Addr())

	const readBufferSize = 8
	logger := logging.NewDefaultLoggerFactory().NewLogger("webrtc")
	tcpMux := webrtc.NewICETCPMux(logger, tcpListener, readBufferSize)
	settingEngine.SetICETCPMux(tcpMux)

	m := &webrtc.MediaEngine{}
	if err := m.RegisterDefaultCodecs(); err != nil {
		return nil, fmt.Errorf("registering default codecs: %w", err)
	}
	api := webrtc.NewAPI(webrtc.WithSettingEngine(settingEngine),
		webrtc.WithMediaEngine(m))

	return api.NewPeerConnection(webrtc.Configuration{
		ICEServers: []webrtc.ICEServer{
			{URLs: []string{"stun:stun.l.google.com:19302"}},
		},
	})
}

The rest of it is the usual signaling dance.

What did you expect?

I expected the peer connection to negotiate ICE over TCP successfully. The browser-based version of this code seems to just automatically negotiate ICE over TCP with no configuration.

What happened?

It did not.

[Sean-Der]

Hey @dgunay

We only support ICE-TCP Passive. I have been tracking it here. If you have the bandwidth I would really love your help implementing it. It shouldn't be difficult and happy to help anyway I can.

[Sean-Der]

We can leave this open/or close as a dupe. w/e you prefer!

[dgunay]

I think we can close this since my issue was resolved (there is an undocumented part of their REST API which enables UDP ICE).

I left a comment on the TCP-ICE issue - yeah I would like to try implementing active TCP ICE. Let me know how I can get started and what parts of the code I should look at.