Also, notice port 3478 in the log printout. That's the STUN/TURN default
iptables log printout:
Apr 6 18:34:45 myhost kernel: [2707541.396456] iptables: IN=eth0 OUT=
MAC=xx.xx.xx.d7:96:92:1c:df:0f:b1:7d:xx.xx.xx SRC=75.xx.xx.xx
DST=79.xx.xx.xx LEN=148 TOS=0x00 PREC=0x00 TTL=45 ID=20303 PROTO=ICMP
TYPE=3 CODE=3 [SRC=79.xx.xx.xx DST=192.168.2.13 LEN=120 TOS=0x00
PREC=0x00 TTL=45 ID=47622 DF PROTO=UDP SPT=3478 DPT=45206 LEN=100 ]
On Sun, Apr 6, 2014 at 3:19 PM, Peter Villeneuve <petervnv1@gmail.com >>> <mailto:petervnv1@gmail.com>> wrote:
On Sun, Apr 6, 2014 at 9:53 AM, Emil Ivov <emcho@jitsi.org >>> <mailto:emcho@jitsi.org>> wrote:
On 05.04.14, 19:35, JJ Janus wrote:
>Your TURN server only needs to have port 80 open to the
world in TCP.
It also needs to allow UDP traffic to and from Jitsi
Videobridge (ports
10000 to 20000 by default).
Thanks Emil. I've got it working now.
Are you sure about those UDP ports?
Pretty much, yeah:
https://github.com/jitsi/__jitsi-videobridge/blob/master/
__src/org/jitsi/videobridge/__Main.java#L59-L73
<https://github.com/jitsi/jitsi-videobridge/blob/master/
src/org/jitsi/videobridge/Main.java#L59-L73>
You can override those when starting the bridge though.
The reason I ask is that I noticed
yesterday problems with people joining the conference
without audio
and/or video.
After I looked at the iptables logs I saw clients trying to
connect to
ports in the 40000 range directly from the internet. Since
those ports
weren't open, obviously media wasn't flowing.
Here's an example:
Apr 4 15:47:56 mymachine kernel: [2524784.462286] iptables:
IN=eth0
OUT= MAC=xx.xx.xx.xx:96:92:1c:df:__0f:b1:7d:xx.xx.xx
SRC=64.xx.xx.xx
DST=79.xx.xx.xx LEN=71 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF
PROTO=UDP
SPT=53 DPT=40102 LEN=51
This seems to be originating from port 53, which is a bit
strange (although it could be just a NAT allocation). Are you
sure that this specific packet was sent from a browser running
Jitsi Meet?
Emil
Yeah, I found it pretty strange too although that IP was from a
Chrome browser in a Jitmeet conference and indeed his video wasn't
showing up in the conference at the time.
Anyway, I'll keep a close eye on the iptables logs and see if this
pops up again.
By the way, just watched your Dangerous Demos video and was very
impressed.
Congrats on the great work the whole Jitsi community has been doing.
Peter
On Sat, Apr 5, 2014 at 3:53 PM, Emil Ivov <emcho@jitsi.org >>> <mailto:emcho@jitsi.org> >>> <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:
On 02.04.14, 17:42, Peter Villeneuve wrote:
Hi,
I've managed to get jitmeet up and running as per
the
instructions here
https://github.com/jitsi/jitsi-meet/pull/43/files?
short_path=7d442b7&unchanged=____collapsed
<https://github.com/jitsi/jitsi-meet/pull/43/files?
short_path=7d442b7&unchanged=__collapsed>
<https://github.com/jitsi/jitsi-meet/pull/43/files?
short_path=7d442b7&unchanged=__collapsed
<https://github.com/jitsi/jitsi-meet/pull/43/files?
short_path=7d442b7&unchanged=collapsed>>
The only issue left is probably firewall related
since audio
from the
conference host is not getting out to the other
participants (but
strangely video seems fine both ways). Audio and
video from invited
participants is fine.
Anyway, looking at the config file for restund turn
server, I
don't see
any option to set the port range for the relayed
UDP traffic, which
means I have to open up the firewall which is
obviously not good.
I've always been a proponent to "just let UDP flow" but
that's
another topic.
Your TURN server only needs to have port 80 open to the
world in
TCP. It also needs to allow UDP traffic to and from
Jitsi
Videobridge (ports 10000 to 20000 by default).
Am I missing something or does restund really not
offer the
option to
set a port range for UDP relaying?
Also, I can't seem to find any errors in the logs
as to why
audio from
the organzier isn't reaching the other
participants. Any clues as to
where I should look further to debug this one
remaining issue?
chrome://webrtc-internals might reveal some clues.
Emil
Thanks
___________________________________________________
dev mailing list
dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
<mailto:dev@jitsi.org>>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/____mailman/listinfo/dev
<http://lists.jitsi.org/__mailman/listinfo/dev>
<http://lists.jitsi.org/__mailman/listinfo/dev
<http://lists.jitsi.org/mailman/listinfo/dev>>
--
https://jitsi.org
___________________________________________________
dev mailing list
dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
<mailto:dev@jitsi.org>>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/____mailman/listinfo/dev
<http://lists.jitsi.org/__mailman/listinfo/dev>
<http://lists.jitsi.org/__mailman/listinfo/dev
<http://lists.jitsi.org/mailman/listinfo/dev>>
_________________________________________________
dev mailing list
dev@jitsi.org <mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/__mailman/listinfo/dev
<http://lists.jitsi.org/mailman/listinfo/dev>
--
https://jitsi.org
_________________________________________________
dev mailing list
dev@jitsi.org <mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/__mailman/listinfo/dev
<http://lists.jitsi.org/mailman/listinfo/dev>
_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev