[jitsi-dev] ICE and STUN/TURN server discovery in Jitsi Android


#1

Hello list,

I have a few questions regarding Jitsi and it's STUN/TURN server discovery, in
particular the Android version.

1) Does Jitsi discover STUN/TURN via srv records as described in rfc5389,
rfc5766 and rfc5928 and in http://wiki.xmpp.org/web/SRV_Records ?

2) Does Jitsi discover STUN/TURN via external service discovery as described
in xep-0215 ?

I am asking this because i have set up a STUN/TURN server and even with DNS
SRV records _and_ prosody's mod_turncredentials (
http://code.google.com/p/prosody-modules/source/browse/mod_turncredentials/mod_turncredentials.lua ) i still
get ICE failed message.

Thank you for any clarifications.

Best regards
  Gryffus


#2

Some additional info:

This is output from my jabber server (prosody with mod_turncredentials):

disco#info:
<query xmlns=“http://jabber.org/protocol/disco#info”>
<identity category=“pubsub” type=“pep” name=“Prosody”/>
<identity category=“server” type=“im” name=“Prosody”/>
<feature var=“http://jabber.org/protocol/commands”/>
<feature var=“http://jabber.org/protocol/pubsub#publish”/>
<feature var=“msgoffline”/>
<feature var=“urn:xmpp:extdisco:1”/>
<feature var=“jabber:iq:privacy”/>
<feature var=“jabber:iq:register”/>
<feature var=“vcard-temp”/>
<feature var=“jabber:iq:roster”/>
<feature var=“urn:xmpp:time”/>
<feature var=“jabber:iq:time”/>
<feature var=“jabber:iq:private”/>
<feature var=“http://jabber.org/protocol/disco#info”/>
<feature var=“http://jabber.org/protocol/disco#items”/>
<feature var=“jabber:iq:version”/>
<feature var=“urn:xmpp:ping”/>
<feature var=“jabber:iq:last”/>
<feature var=“urn:xmpp:carbons:2”/>
<feature var=“urn:xmpp:carbons:1”/>
</query>

extdisco:
<services xmlns="urn:xmpp:extdisco:1">
<service port="3478" host="myip" type="stun"/>
<service port="3478" password="mysecret" ttl="86400" username="myusername"
host="myip" type="turn"/>
</services>

Using resiprocate STUN/TURN server.

One more question:

Does resiprocate username/password stored in it's configuration need to be the
same as reported from extdisco or it is autogenerated? Because it looks like
the password and username i get from extdisco is random/one-time.

Best regards
  Gryffus

Dne Pá 28. února 2014 15:31:06, Lukáš Krejza napsal(a):

···

Hello list,

I have a few questions regarding Jitsi and it's STUN/TURN server discovery,
in particular the Android version.

1) Does Jitsi discover STUN/TURN via srv records as described in rfc5389,
rfc5766 and rfc5928 and in http://wiki.xmpp.org/web/SRV_Records ?

2) Does Jitsi discover STUN/TURN via external service discovery as described
in xep-0215 ?

I am asking this because i have set up a STUN/TURN server and even with DNS
SRV records _and_ prosody's mod_turncredentials (
http://code.google.com/p/prosody-modules/source/browse/mod_turncredentials/m
od_turncredentials.lua ) i still get ICE failed message.

Thank you for any clarifications.

Best regards
  Gryffus

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Does resiprocate username/password stored in it's configuration need to be the
same as reported from extdisco or it is autogenerated? Because it looks like
the password and username i get from extdisco is random/one-time.

mod_turncredentials implements http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 and only that. The only TURN servers that I am aware of that implement this are rfc5766-turn-server and a patched version of restund.

Jitsi doesn't support this yet, it's part of a GSOC project:
https://jitsi.org/GSOC/AdvancedNATTraversal


#4

And what about TURN server discovery via DNS?

Dne Pá 28. února 2014 17:19:29, Philipp Hancke napsal(a):

···

> Does resiprocate username/password stored in it's configuration need to be
> the same as reported from extdisco or it is autogenerated? Because it
> looks like the password and username i get from extdisco is
> random/one-time.

mod_turncredentials implements
http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 and only
that. The only TURN servers that I am aware of that implement this are
rfc5766-turn-server and a patched version of restund.

Jitsi doesn't support this yet, it's part of a GSOC project:
https://jitsi.org/GSOC/AdvancedNATTraversal

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Hey Lukáš,

Yes, Jitsi auto discovers STUN and TURN servers on the local domain, using SRV records. It would try authenticating there with the same user name and password as the one you have for your XMPP account.

We'll soon try implementing support for TURN discovery through XMPP as Philipp mentioned.

Cheers,
Emil

···

On 28.02.2014, at 19:49, Lukáš Krejza <lukas.krejza@hespro.cz> wrote:

And what about TURN server discovery via DNS?

Dne Pá 28. února 2014 17:19:29, Philipp Hancke napsal(a):

Does resiprocate username/password stored in it's configuration need to be
the same as reported from extdisco or it is autogenerated? Because it
looks like the password and username i get from extdisco is
random/one-time.

mod_turncredentials implements
http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 and only
that. The only TURN servers that I am aware of that implement this are
rfc5766-turn-server and a patched version of restund.

Jitsi doesn't support this yet, it's part of a GSOC project:
https://jitsi.org/GSOC/AdvancedNATTraversal

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
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

--
https://jitsi.org


#6

Hi Emil,

What do you mean on the local domain? I have a public Jabber server, let's
name it myserver.org. If Jitsi connects to jid@myserver.org, does it discover
STUN/TURN server by digging one of these: _stun._udp.myserver.org,
_stun._tcp.myserver.org, _turn._udp.myserver.org, _turn._tcp.myserver.org ? Or
do you mean only zeroconf? If it's only zeroconf then how do i supply the
STUN/TURN server address to the clients via i.e. mobile network?

What type of STUN/TURN server does Jitsi support? Do you have some tested? I
tried rfc5766-turn-server and resiprocate-turn-server but neither worked even
if i set it up manually in the jitsi settings... :frowning:

I would be glad for any help with testing or setting up. I can help you with
Jitsi translation and/or some debugging in return if you are interested.

Thank you very much,

Best regards,
  Lukas

Dne So 1. března 2014 14:57:50 jste napsal(a):

···

Hey Lukáš,

Yes, Jitsi auto discovers STUN and TURN servers on the local domain, using
SRV records. It would try authenticating there with the same user name and
password as the one you have for your XMPP account.

We'll soon try implementing support for TURN discovery through XMPP as
Philipp mentioned.

Cheers,
Emil

On 28.02.2014, at 19:49, Lukáš Krejza <lukas.krejza@hespro.cz> wrote:
> And what about TURN server discovery via DNS?
>
> Dne Pá 28. února 2014 17:19:29, Philipp Hancke napsal(a):
>>> Does resiprocate username/password stored in it's configuration need to
>>> be
>>> the same as reported from extdisco or it is autogenerated? Because it
>>> looks like the password and username i get from extdisco is
>>> random/one-time.
>>
>> mod_turncredentials implements
>> http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 and only
>> that. The only TURN servers that I am aware of that implement this are
>> rfc5766-turn-server and a patched version of restund.
>>
>> Jitsi doesn't support this yet, it's part of a GSOC project:
>> https://jitsi.org/GSOC/AdvancedNATTraversal
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> 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


#7

Hi Emil,

What do you mean on the local domain? I have a public Jabber server, let's
name it myserver.org. If Jitsi connects to jid@myserver.org, does it discover
STUN/TURN server by digging one of these: _stun._udp.myserver.org,

yes. have you tried and found otherwise?

_stun._tcp.myserver.org,

No ... I don't think we'd be interested in doing ICE-TCP

_turn._udp.myserver.org,

Yes.

_turn._tcp.myserver.org ?

No, because we don't yet support TURN/TCP

Or
do you mean only zeroconf? If it's only zeroconf then how do i supply the
STUN/TURN server address to the clients via i.e. mobile network?

I don't understand what you mean by zeroconf here. Is it on-line provisioning?

What type of STUN/TURN server does Jitsi support? Do you have some tested?

turnserver.org

I
tried rfc5766-turn-server and resiprocate-turn-server but neither worked even
if i set it up manually in the jitsi settings... :frowning:

Why? What happened?

Emil

···

On Mon, Mar 3, 2014 at 8:34 AM, Lukáš Krejza <lukas.krejza@hespro.cz> wrote:

I would be glad for any help with testing or setting up. I can help you with
Jitsi translation and/or some debugging in return if you are interested.

Thank you very much,

Best regards,
        Lukas

Dne So 1. března 2014 14:57:50 jste napsal(a):

Hey Lukáš,

Yes, Jitsi auto discovers STUN and TURN servers on the local domain, using
SRV records. It would try authenticating there with the same user name and
password as the one you have for your XMPP account.

We'll soon try implementing support for TURN discovery through XMPP as
Philipp mentioned.

Cheers,
Emil

On 28.02.2014, at 19:49, Lukáš Krejza <lukas.krejza@hespro.cz> wrote:
> And what about TURN server discovery via DNS?
>
> Dne Pá 28. února 2014 17:19:29, Philipp Hancke napsal(a):
>>> Does resiprocate username/password stored in it's configuration need to
>>> be
>>> the same as reported from extdisco or it is autogenerated? Because it
>>> looks like the password and username i get from extdisco is
>>> random/one-time.
>>
>> mod_turncredentials implements
>> http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 and only
>> that. The only TURN servers that I am aware of that implement this are
>> rfc5766-turn-server and a patched version of restund.
>>
>> Jitsi doesn't support this yet, it's part of a GSOC project:
>> https://jitsi.org/GSOC/AdvancedNATTraversal
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> 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

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#8

Dne Út 4. března 2014 10:41:22, Emil Ivov napsal(a):

> Hi Emil,
>
> What do you mean on the local domain? I have a public Jabber server, let's
> name it myserver.org. If Jitsi connects to jid@myserver.org, does it
> discover STUN/TURN server by digging one of these:
> _stun._udp.myserver.org,
yes. have you tried and found otherwise?

Well if i connect without manually configured STUN/TURN server i got nothing
in the logs about Jitsi even trying to connect to it...

> _stun._tcp.myserver.org,

No ... I don't think we'd be interested in doing ICE-TCP

> _turn._udp.myserver.org,

Yes.

> _turn._tcp.myserver.org ?

No, because we don't yet support TURN/TCP

> Or
> do you mean only zeroconf? If it's only zeroconf then how do i supply the
> STUN/TURN server address to the clients via i.e. mobile network?

I don't understand what you mean by zeroconf here. Is it on-line
provisioning?

By zeroconf i mean Avahi/Bonjour/mDNS, which works only on local domain AFAIK.
But you replied to this question above.

> What type of STUN/TURN server does Jitsi support? Do you have some tested?

turnserver.org

Ok, i will try this one. Any advices how to set it up properly?

> I
> tried rfc5766-turn-server and resiprocate-turn-server but neither worked
> even if i set it up manually in the jitsi settings... :frowning:

Why? What happened?

ICE failed:

turnserver -v --syslog -L 62.77.84.153 -E 62.77.84.153 --max-bps=3000000 -f -m
3 --min-port=65335 --max-port=65535 --no-tls --no-dtls --no-auth

0:
RFC 3489/5389/5766/5780/6062/6156 STUN/TURN Server
Version Citrix-3.2.2.8 'Marshal West'
0:
Max number of open files/sockets allowed for this process: 4096
0:
Due to the open files/sockets limitation,
max supported number of TURN Sessions possible is: 2000 (approximately)
0:

==== Show him the instruments, Practical Frost: ====

0: TLS supported
0: DTLS supported
0: Redis supported
0: PostgreSQL is not supported
0: MySQL is not supported
0: OpenSSL version: fresh enough
0: Default Net Engine version: 3 (UDP thread per CPU core)

···

On Mon, Mar 3, 2014 at 8:34 AM, Lukáš Krejza <lukas.krejza@hespro.cz> wrote:

=====================================================

0: Config file found: /root/rfc5766-turn-server-read-
only/examples/etc/turnserver.conf
0: Listener address to use: 62.77.84.153
0: Relay address to use: 62.77.84.153
0: 3000000 bytes per second is allowed per session
0: Config file found: /root/rfc5766-turn-server-read-
only/examples/etc/turnserver.conf
0: Config file found: /root/rfc5766-turn-server-read-
only/examples/etc/turnuserdb.conf
0: pid file created: /var/run/turnserver.pid
0: IO method (main listener thread): epoll (with changelist)
0: WARNING: I cannot support STUN CHANGE_REQUEST functionality because only
one IP address is provided
0: Wait for relay ports initialization...
0: relay 62.77.84.153 initialization...
0: relay 62.77.84.153 initialization done
0: Relay ports initialization done
0: IO method (general relay thread): epoll (with changelist)
0: IO method (general relay thread): epoll (with changelist)
0: turn server id=1 created
0: turn server id=0 created
0: IPv4. TCP listener opened on : 62.77.84.153:3478
0: IPv4. TCP listener opened on : 62.77.84.153:3478
0: IO method (general relay thread): epoll (with changelist)
0: turn server id=2 created
0: IPv4. TCP listener opened on : 62.77.84.153:3478
0: IPv4. UDP listener opened on: 62.77.84.153:3478
0: IO method (auth thread): epoll (with changelist)
0: IO method (cli thread): epoll (with changelist)
0: IPv4. CLI listener opened on : 127.0.0.1:5766
16: handle_udp_packet: New UDP endpoint: local addr 62.77.84.153:3478, remote
addr 62.77.84.165:5000
16: IPv4. Server relay addr: 62.77.84.153:0
16: IPv4. Local relay addr: 62.77.84.153:65507
16: new: session id=001000000000000001, username=<>, lifetime=600
16: user <>: incoming packet ALLOCATE processed, success
16: user <>: incoming packet ALLOCATE processed, error 437
16: user <>: incoming packet message processed, error 437
16: user <>: incoming packet BINDING processed, success
18: handle_udp_packet: New UDP endpoint: local addr 62.77.84.153:3478, remote
addr 62.77.84.165:5001
18: IPv4. Server relay addr: 62.77.84.153:0
18: IPv4. Local relay addr: 62.77.84.153:65335
18: new: session id=001000000000000002, username=<>, lifetime=600
18: user <>: incoming packet ALLOCATE processed, success
18: user <>: incoming packet ALLOCATE processed, error 437
18: user <>: incoming packet message processed, error 437
18: user <>: incoming packet BINDING processed, success
23: user <>: incoming packet CREATE_PERMISSION processed, success
23: user <>: incoming packet CREATE_PERMISSION processed, success
31: refreshed: session id=001000000000000001, username=<>, lifetime=0
31: user <>: incoming packet REFRESH processed, success
31: refreshed: session id=001000000000000002, username=<>, lifetime=0
31: user <>: incoming packet REFRESH processed, success
32: TURN connection closed (non-mobile pattern), user <>
32: TURN connection closed (non-mobile pattern), user <>

Emil

> I would be glad for any help with testing or setting up. I can help you
> with Jitsi translation and/or some debugging in return if you are
> interested.
>
> Thank you very much,
>
> Best regards,
>
> Lukas
>
> Dne So 1. března 2014 14:57:50 jste napsal(a):
>> Hey Lukáš,
>>
>> Yes, Jitsi auto discovers STUN and TURN servers on the local domain,
>> using
>> SRV records. It would try authenticating there with the same user name
>> and
>> password as the one you have for your XMPP account.
>>
>> We'll soon try implementing support for TURN discovery through XMPP as
>> Philipp mentioned.
>>
>> Cheers,
>> Emil
>>
>> On 28.02.2014, at 19:49, Lukáš Krejza <lukas.krejza@hespro.cz> wrote:
>> > And what about TURN server discovery via DNS?
>> >
>> > Dne Pá 28. února 2014 17:19:29, Philipp Hancke napsal(a):
>> >>> Does resiprocate username/password stored in it's configuration need
>> >>> to
>> >>> be
>> >>> the same as reported from extdisco or it is autogenerated? Because it
>> >>> looks like the password and username i get from extdisco is
>> >>> random/one-time.
>> >>
>> >> mod_turncredentials implements
>> >> http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 and only
>> >> that. The only TURN servers that I am aware of that implement this are
>> >> rfc5766-turn-server and a patched version of restund.
>> >>
>> >> Jitsi doesn't support this yet, it's part of a GSOC project:
>> >> https://jitsi.org/GSOC/AdvancedNATTraversal
>> >>
>> >> _______________________________________________
>> >> dev mailing list
>> >> dev@jitsi.org
>> >> Unsubscribe instructions and other list options:
>> >> 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
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev


#9

Ok, so i installed turn server from turnserver.org, set up 2 accounts and
tested it and here are the results:

Client 1 has STUN account test1234, Client2 has STUN account test123

Call 1 - Client1 -> Client2
Client 1 Jitsi log:
http://pastebin.com/iaBhxxji ( outgoing )

Client 2 Jitsi log:
http://pastebin.com/xJzKBfsx ( incoming )

Call 2 - Client2 -> Client1
Client 1 Jitsi log:
http://pastebin.com/xJzKBfsx ( incoming )

Client 2 Jitsi log:
http://pastebin.com/cUj73iKW ( outgoing )

STUN/TURN Server log:
http://pastebin.com/cvUKv6fw

Still getting ICE failed.

What do i do wrong? :frowning:

Best Regards,
  Lukas Krejza

Dne Út 4. března 2014 11:59:32, Lukáš Krejza napsal(a):

···

Dne Út 4. března 2014 10:41:22, Emil Ivov napsal(a):
> On Mon, Mar 3, 2014 at 8:34 AM, Lukáš Krejza <lukas.krejza@hespro.cz> wrote:
> > Hi Emil,
> >
> > What do you mean on the local domain? I have a public Jabber server,
> > let's
> > name it myserver.org. If Jitsi connects to jid@myserver.org, does it
> > discover STUN/TURN server by digging one of these:
> > _stun._udp.myserver.org,
>
> yes. have you tried and found otherwise?

Well if i connect without manually configured STUN/TURN server i got nothing
in the logs about Jitsi even trying to connect to it...

> > _stun._tcp.myserver.org,
>
> No ... I don't think we'd be interested in doing ICE-TCP
>
> > _turn._udp.myserver.org,
>
> Yes.
>
> > _turn._tcp.myserver.org ?
>
> No, because we don't yet support TURN/TCP
>
> > Or
> > do you mean only zeroconf? If it's only zeroconf then how do i supply
> > the
> > STUN/TURN server address to the clients via i.e. mobile network?
>
> I don't understand what you mean by zeroconf here. Is it on-line
> provisioning?

By zeroconf i mean Avahi/Bonjour/mDNS, which works only on local domain
AFAIK. But you replied to this question above.

> > What type of STUN/TURN server does Jitsi support? Do you have some
> > tested?
>
> turnserver.org

Ok, i will try this one. Any advices how to set it up properly?

> > I
> > tried rfc5766-turn-server and resiprocate-turn-server but neither worked
> > even if i set it up manually in the jitsi settings... :frowning:
>
> Why? What happened?

ICE failed:

turnserver -v --syslog -L 62.77.84.153 -E 62.77.84.153 --max-bps=3000000 -f
-m 3 --min-port=65335 --max-port=65535 --no-tls --no-dtls --no-auth

0:
RFC 3489/5389/5766/5780/6062/6156 STUN/TURN Server
Version Citrix-3.2.2.8 'Marshal West'
0:
Max number of open files/sockets allowed for this process: 4096
0:
Due to the open files/sockets limitation,
max supported number of TURN Sessions possible is: 2000 (approximately)
0:

==== Show him the instruments, Practical Frost: ====

0: TLS supported
0: DTLS supported
0: Redis supported
0: PostgreSQL is not supported
0: MySQL is not supported
0: OpenSSL version: fresh enough
0: Default Net Engine version: 3 (UDP thread per CPU core)

=====================================================

0: Config file found: /root/rfc5766-turn-server-read-
only/examples/etc/turnserver.conf
0: Listener address to use: 62.77.84.153
0: Relay address to use: 62.77.84.153
0: 3000000 bytes per second is allowed per session
0: Config file found: /root/rfc5766-turn-server-read-
only/examples/etc/turnserver.conf
0: Config file found: /root/rfc5766-turn-server-read-
only/examples/etc/turnuserdb.conf
0: pid file created: /var/run/turnserver.pid
0: IO method (main listener thread): epoll (with changelist)
0: WARNING: I cannot support STUN CHANGE_REQUEST functionality because only
one IP address is provided
0: Wait for relay ports initialization...
0: relay 62.77.84.153 initialization...
0: relay 62.77.84.153 initialization done
0: Relay ports initialization done
0: IO method (general relay thread): epoll (with changelist)
0: IO method (general relay thread): epoll (with changelist)
0: turn server id=1 created
0: turn server id=0 created
0: IPv4. TCP listener opened on : 62.77.84.153:3478
0: IPv4. TCP listener opened on : 62.77.84.153:3478
0: IO method (general relay thread): epoll (with changelist)
0: turn server id=2 created
0: IPv4. TCP listener opened on : 62.77.84.153:3478
0: IPv4. UDP listener opened on: 62.77.84.153:3478
0: IO method (auth thread): epoll (with changelist)
0: IO method (cli thread): epoll (with changelist)
0: IPv4. CLI listener opened on : 127.0.0.1:5766
16: handle_udp_packet: New UDP endpoint: local addr 62.77.84.153:3478,
remote addr 62.77.84.165:5000
16: IPv4. Server relay addr: 62.77.84.153:0
16: IPv4. Local relay addr: 62.77.84.153:65507
16: new: session id=001000000000000001, username=<>, lifetime=600
16: user <>: incoming packet ALLOCATE processed, success
16: user <>: incoming packet ALLOCATE processed, error 437
16: user <>: incoming packet message processed, error 437
16: user <>: incoming packet BINDING processed, success
18: handle_udp_packet: New UDP endpoint: local addr 62.77.84.153:3478,
remote addr 62.77.84.165:5001
18: IPv4. Server relay addr: 62.77.84.153:0
18: IPv4. Local relay addr: 62.77.84.153:65335
18: new: session id=001000000000000002, username=<>, lifetime=600
18: user <>: incoming packet ALLOCATE processed, success
18: user <>: incoming packet ALLOCATE processed, error 437
18: user <>: incoming packet message processed, error 437
18: user <>: incoming packet BINDING processed, success
23: user <>: incoming packet CREATE_PERMISSION processed, success
23: user <>: incoming packet CREATE_PERMISSION processed, success
31: refreshed: session id=001000000000000001, username=<>, lifetime=0
31: user <>: incoming packet REFRESH processed, success
31: refreshed: session id=001000000000000002, username=<>, lifetime=0
31: user <>: incoming packet REFRESH processed, success
32: TURN connection closed (non-mobile pattern), user <>
32: TURN connection closed (non-mobile pattern), user <>

> Emil
>
> > I would be glad for any help with testing or setting up. I can help you
> > with Jitsi translation and/or some debugging in return if you are
> > interested.
> >
> > Thank you very much,
> >
> > Best regards,
> >
> > Lukas
> >
> > Dne So 1. března 2014 14:57:50 jste napsal(a):
> >> Hey Lukáš,
> >>
> >> Yes, Jitsi auto discovers STUN and TURN servers on the local domain,
> >> using
> >> SRV records. It would try authenticating there with the same user name
> >> and
> >> password as the one you have for your XMPP account.
> >>
> >> We'll soon try implementing support for TURN discovery through XMPP as
> >> Philipp mentioned.
> >>
> >> Cheers,
> >> Emil
> >>
> >> On 28.02.2014, at 19:49, Lukáš Krejza <lukas.krejza@hespro.cz> wrote:
> >> > And what about TURN server discovery via DNS?
> >> >
> >> > Dne Pá 28. února 2014 17:19:29, Philipp Hancke napsal(a):
> >> >>> Does resiprocate username/password stored in it's configuration
> >> >>> need
> >> >>> to
> >> >>> be
> >> >>> the same as reported from extdisco or it is autogenerated? Because
> >> >>> it
> >> >>> looks like the password and username i get from extdisco is
> >> >>> random/one-time.
> >> >>
> >> >> mod_turncredentials implements
> >> >> http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 and only
> >> >> that. The only TURN servers that I am aware of that implement this
> >> >> are
> >> >> rfc5766-turn-server and a patched version of restund.
> >> >>
> >> >> Jitsi doesn't support this yet, it's part of a GSOC project:
> >> >> https://jitsi.org/GSOC/AdvancedNATTraversal
> >> >>
> >> >> _______________________________________________
> >> >> dev mailing list
> >> >> dev@jitsi.org
> >> >> Unsubscribe instructions and other list options:
> >> >> 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
> >
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org
> > Unsubscribe instructions and other list options:
> > 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


#10

Hello,

Ok, so i installed turn server from turnserver.org, set up 2 accounts and
tested it and here are the results:

Client 1 has STUN account test1234, Client2 has STUN account test123

Call 1 - Client1 -> Client2
Client 1 Jitsi log:
http://pastebin.com/iaBhxxji ( outgoing )

Client 2 Jitsi log:
http://pastebin.com/xJzKBfsx ( incoming )

The addresses here don't match, I'm assuming that it's a copy/paste
error, because the second one is also linked below (where it does make
sense).

Call 2 - Client2 -> Client1
Client 1 Jitsi log:
http://pastebin.com/xJzKBfsx ( incoming )

Client 2 Jitsi log:
http://pastebin.com/cUj73iKW ( outgoing )

STUN/TURN Server log:
http://pastebin.com/cvUKv6fw

The client at 192.168.24.120 connects to your stun/turn server, the one
at 10.139.91.238 doesn't. I don't know why that is. You should make sure
that the stun/turn server is accessible from 10.139.91.238, and look for
differences in the client configurations.

Regards,
Boris

···

On 04/03/14 17:22, Lukáš Krejza wrote: