Janus-gateway: Streaming plugin not releasing Ports

Created on 15 Mar 2018  路  8Comments  路  Source: meetecho/janus-gateway

The streaming plugin doesn't seem to be releasing ports even after ending all sessions, plugin handles, incoming rtp. Below is even after 12 hours...:

  [WSS-0x7f7f7005f9a0] WebSocket connection opened from 127.0.0.1
  Checking if 127.0.0.1 is allowed to contact janus interface
  Yep
  [WSS-0x7f7f7005f9a0] WebSocket connection accepted
  [WSS-0x7f7f7005f9a0]   -- Ready to be used!
  Got a Janus API request from janus.transport.websockets (0x7f7f7005efd0)
  Creating new session: 2104775536196556
  Got a Janus API request from janus.transport.websockets (0x7f7f7005efd0)
  Creating new handle in session 2104775536196556: 1788892421402601
  Got a Janus API request from janus.transport.websockets (0x7f7f7005efd0)
  Transport task pool, serving request
  [1788892421402601] There's a message for JANUS Streaming plugin
  Audio enabled, Video enabled
  Missing name, will generate a random one...
  Audio enabled, Video enabled, Data NOT enabled
  [ERR] [plugins/janus_streaming.c:janus_streaming_create_fd:3242] [9804185259702556] Bind failed for audio (port 5521)...
  [ERR] [plugins/janus_streaming.c:janus_streaming_create_rtp_source:3421] Can't bind to port 5521 for audio...
  [ERR] [plugins/janus_streaming.c:janus_streaming_handle_message:1771] Error creating 'rtp' stream...

~# lsof -i:5520
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
janus   2184 root   39u  IPv4  33345      0t0  UDP *:5520 
~# lsof -i:5521
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
janus   2184 root   30u  IPv4  33344      0t0  UDP *:5521 
~# lsof -i:5522
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
janus   2184 root   34u  IPv4  45402      0t0  UDP *:5522 
~# lsof -i:5523
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
janus   2184 root   25u  IPv4  45401      0t0  UDP *:5523 
~# lsof -i:5524
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
janus   2184 root   56u  IPv4  52025      0t0  UDP *:5524 
~# lsof -i:5525
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
janus   2184 root   36u  IPv4  52024      0t0  UDP *:5525

Ports that have been used previously

~# lsof -i:5625
~#

Jumping 100 ports ahead, it's clear which is expect, this port has never been used by janus

Any ideas? My current workaround will be to let Janus randomly choose from 20k ports and restart, when no active sessions are around...

Thanks,

  • Rob

Most helpful comment

@RobertLowe maybe a naive question, but are you effectively destroying the mountpoints? Closing all sessions and stopping the incoming RTP is not enough.

All 8 comments

Are you sure you are not trying to create a mountpoint using a set of ports already used by another mountpoint in the configuration or in a previous request?
To effectively count the UDP fds used by Janus, issue:
lsof -i UDP -a -p $(pidof janus) | wc -l

@atoppi not the case, the ports were claimed sequencely, after resetting the sequence back (long after the sessions, plugin handles, incoming rtp streams ended - like 12hours+) none of those ports were accessible and still binded by Janus

Are you confident those are mountpoint ports and not, let's say, ports used for ICE on the WebRTC side?

We definitely have code to close all sockets (and thus release all ports) when a mountpoint is destroyed:

https://github.com/meetecho/janus-gateway/blob/master/plugins/janus_streaming.c#L3261

You may want to check if for some reason that code is never called for you even when destroying a mountpoint.

@RobertLowe maybe a naive question, but are you effectively destroying the mountpoints? Closing all sessions and stopping the incoming RTP is not enough.

@lminiero yes, mountpoint ports videoport, audioport.

@atoppi ah, I'm the naive one, I think your right., I'm destroying the sessions, detaching plugins, and ending RTP connections. I assumed detaching plugin handles, destroying sessions would also destroy their plugin handle and release the mountpoint after everything had gone away. I'll verify destroying explicitly closes ports.

Thanks you @lminiero & @atoppi we can close this, I can open a PR to update docs, any suggestions?

Ack, closing then.

As to the docs, I don't believe we need any to clarify this, actually. Streaming mountpoints are static and independent of who starts watching them and when: it's the same thing for conference rooms in all plugins implementing them (AudioBridge, VideoRoom, TextRoom). One creates a mountpoint/room, people come and go, and then only destroys it when it's not needed anymore.

Thank you @lminiero

Was this page helpful?
0 / 5 - 0 ratings