[jitsi-users] Configure port range used in ICE negotiations


#1

Hello everyone,

As I still wasn't able to find that one out, could anybody help how to configure the port range (current default seems to be 5000-6000) used in ICE negotiations? (They do not seem to be affected by setting the properties "net.java.sip.communicator.service.media.MIN_PORT_NUMBER" or "net.java.sip.communicator.service.protocol.MIN_MEDIA_PORT_NUMBER"...) Thanks.

Regards, Adam.


#2

Could you please try SVN r8795 which should take the configuration
property net.java.sip.communicator.service.protocol.MIN_MEDIA_PORT_NUMBER
into account even for the purposes of ICE?

···

On Fri, Jul 22, 2011 at 9:44 AM, Adam Reichold <adam.reichold@t-online.de> wrote:

As I still wasn't able to find that one out, could anybody help how to
configure the port range (current default seems to be 5000-6000) used in ICE
negotiations? (They do not seem to be affected by setting the properties
"net.java.sip.communicator.service.media.MIN_PORT_NUMBER" or
"net.java.sip.communicator.service.protocol.MIN_MEDIA_PORT_NUMBER"...)


#3

Gladly! But how do the SVN revisions correspond to the version numbers of the nightly builds? Can I use the current nightly build 3593? (As I understood it, I need a Java.net account to checkout your SVN repository. And then I do not have a Java toolchain set up anyway... :-\ So I'd really prefer using a nightly build.)

···

Am 26.07.2011, 16:55 Uhr, schrieb Lyubomir Marinov <lubo@jitsi.org>:

On Fri, Jul 22, 2011 at 9:44 AM, Adam Reichold > <adam.reichold@t-online.de> wrote:

As I still wasn't able to find that one out, could anybody help how to
configure the port range (current default seems to be 5000-6000) used in ICE
negotiations? (They do not seem to be affected by setting the properties
"net.java.sip.communicator.service.media.MIN_PORT_NUMBER" or
"net.java.sip.communicator.service.protocol.MIN_MEDIA_PORT_NUMBER"...)

Could you please try SVN r8795 which should take the configuration
property net.java.sip.communicator.service.protocol.MIN_MEDIA_PORT_NUMBER
into account even for the purposes of ICE?


#4

Thank you! I'll let you know the nightly build number once it's available.

···

On Tue, Jul 26, 2011 at 6:27 PM, Adam Reichold <adamreichold@myopera.com> wrote:

Gladly! But how do the SVN revisions correspond to the version numbers of
the nightly builds? Can I use the current nightly build 3593? (As I
understood it, I need a Java.net account to checkout your SVN repository.
And then I do not have a Java toolchain set up anyway... :-\ So I'd really
prefer using a nightly build.)


#5

Adam, could you please try the latest nightly build from
http://download.jitsi.org/jitsi/nightly/ which is currently at number
3597? The port range is defined by the configuration properties
net.java.sip.communicator.service.protocol.MIN_MEDIA_PORT_NUMBER and
net.java.sip.communicator.service.protocol.MAX_MEDIA_PORT_NUMBER which
default to 5000 and 6000 respectively. The minimum is expected to be
less than or equal to the maximum so if you want to set the minimum
beyond 6000, you'll have to set the maximum as well to an appropriate
value.


#6

Success. I tested nightly build 3597 with gabble.echo@test.collabora.co.uk and the log files indicate that my settings were respected, i.e. the correct port range was used in ICE negotiations. (Of course, I have yet to find out, how much this will help with some more buddys and their respective configurations.)

One last question: For security concerns, I'd like to make the forwarded port range as small as possible. Will Jitsi cycle through the configured range, i.e. will it restart at MIN_MEDIA_PORT_NUMBER if it hits MAX_MEDIA_PORT_NUMBER? If so, how many concurrent bindings will Jitsi approximately use for example per connection? Do you think a range of 32 ports is sufficient?

Thanks for your help. Regards, Adam.

···

Am 26.07.2011, 23:22 Uhr, schrieb Lyubomir Marinov <lubo@jitsi.org>:

Adam, could you please try the latest nightly build from
http://download.jitsi.org/jitsi/nightly/ which is currently at number
3597? The port range is defined by the configuration properties
net.java.sip.communicator.service.protocol.MIN_MEDIA_PORT_NUMBER and
net.java.sip.communicator.service.protocol.MAX_MEDIA_PORT_NUMBER which
default to 5000 and 6000 respectively. The minimum is expected to be
less than or equal to the maximum so if you want to set the minimum
beyond 6000, you'll have to set the maximum as well to an appropriate
value.


#7

When ICE is in use, MAX_MEDIA_PORT_NUMBER will mostly be ignored.
Otherwise (e.g. SIP calls), it is taken into account and Jitsi will
"cycle" through the range. We do not have current plans to modify that
behavior in the near future.

···

On Wed, Jul 27, 2011 at 10:21 AM, Adam Reichold <adamreichold@myopera.com> wrote:

One last question: For security concerns, I'd like to make the forwarded
port range as small as possible. Will Jitsi cycle through the configured
range, i.e. will it restart at MIN_MEDIA_PORT_NUMBER if it hits
MAX_MEDIA_PORT_NUMBER?


#8

Thank you for the clarification. I should make some headroom then...

By the way, this really seemed to have helped with some of my connectivity problems. There are at least two people which I can call now without using a Jingle relay and could not do so before the change.

···

Am 01.08.2011, 21:39 Uhr, schrieb Lyubomir Marinov <lubo@jitsi.org>:

On Wed, Jul 27, 2011 at 10:21 AM, Adam Reichold > <adamreichold@myopera.com> wrote:

One last question: For security concerns, I'd like to make the forwarded
port range as small as possible. Will Jitsi cycle through the configured
range, i.e. will it restart at MIN_MEDIA_PORT_NUMBER if it hits
MAX_MEDIA_PORT_NUMBER?

When ICE is in use, MAX_MEDIA_PORT_NUMBER will mostly be ignored.
Otherwise (e.g. SIP calls), it is taken into account and Jitsi will
"cycle" through the range. We do not have current plans to modify that
behavior in the near future.


#9

Hi Adam,

would you please explain in more detail what exactly helped you with
some of your connectivity problems? What did you do so that two people
can now be reached without using a Jingle relay?

How do you observe whether or not Jingle node relay is being used or
not?

Regards, Earl

···

On 8/2/2011 8:56 AM, Adam Reichold wrote:

Thank you for the clarification. I should make some headroom then...

By the way, this really seemed to have helped with some of my connectivity problems. There are at least two people which I can call now without using a Jingle relay and could not do so before the change.

Am 01.08.2011, 21:39 Uhr, schrieb Lyubomir Marinov <lubo@jitsi.org>:

On Wed, Jul 27, 2011 at 10:21 AM, Adam Reichold >> <adamreichold@myopera.com> wrote:

One last question: For security concerns, I'd like to make the forwarded
port range as small as possible. Will Jitsi cycle through the configured
range, i.e. will it restart at MIN_MEDIA_PORT_NUMBER if it hits
MAX_MEDIA_PORT_NUMBER?

When ICE is in use, MAX_MEDIA_PORT_NUMBER will mostly be ignored.
Otherwise (e.g. SIP calls), it is taken into account and Jitsi will
"cycle" through the range. We do not have current plans to modify that
behavior in the near future.


#10

How did I observe that a Jingle node relay was or wasn't used: I read the log files which can by found through http://www.jitsi.org/index.php/Documentation/FAQ#logs and check whether any Jingle relay nodes where discovered. Also the output concerning ICE is quite verbose so you can see which ports and methods of establishing a connection are used. Using that information I disabled my Jabber accounts which would provide a Jingle relay node and checked again that zero discovered relay nodes where logged. (On a Unix-like operating system, doing "tail -f ~/.jitsi/log/sip-communicator0.log.0" in a terminal while running Jitsi is quite helpful.)

What type of problem was cured: I have one friend who used a configuration such that ingoing and outgoing calls between would always fail due to an "ICE failure". We are both using DSL lines and are sitting behind consumer-grade routers. The log files indicate that while STUN discovery of public IP adresses worked, the firewall of our routers were quite strict about UDP traffic. We were able to establish connections by activating UPnP on his side but he considers it a security problem and my router does not even support UPnP. (Well it is disabled in the firmware by the manufacturer again for security reasons.) Therefore I set up manual port forwarding of UDP traffic in a certain quite narrow port range on my router and with ICE using those ports we could again establish a connection. (I needed different than default ports because I did not want to open 1000 ports and because there are several computers on my network which get different port ranges forwarded to them.)

I think in the end the problem is the lousy quality of (and the limit of amount of control over) those consumer-grade routers, but getting ICE to use specific ports which I manually forwarded so that I do not need to rely on the stateful filtering of the firewall of my router. I hope this helps to explain what we did in this specific case. (I have a lot of other people behind DSL routers that I do not have any connection problems with...) But feel free to inquire if you need more details.

Regards, Adam.

P.S.: One could probably argue that opening 32 ports isn't necessarily more secure than opening 3200 ports especially if there is no service configured to continually listen on these ports anyway. But maybe being paranoid about opening ports to the internet isn't the worst one could do... What do you think?

···

Am 05.08.2011, 20:47 Uhr, schrieb Earl <Large.Files@gmx.net>:

Hi Adam,

would you please explain in more detail what exactly helped you with
some of your connectivity problems? What did you do so that two people
can now be reached without using a Jingle relay?

How do you observe whether or not Jingle node relay is being used or
not?

Regards, Earl

On 8/2/2011 8:56 AM, Adam Reichold wrote:

Thank you for the clarification. I should make some headroom then...

By the way, this really seemed to have helped with some of my
connectivity problems. There are at least two people which I can call
now without using a Jingle relay and could not do so before the change.

Am 01.08.2011, 21:39 Uhr, schrieb Lyubomir Marinov <lubo@jitsi.org>:

On Wed, Jul 27, 2011 at 10:21 AM, Adam Reichold >>> <adamreichold@myopera.com> wrote:

One last question: For security concerns, I'd like to make the
forwarded
port range as small as possible. Will Jitsi cycle through the
configured
range, i.e. will it restart at MIN_MEDIA_PORT_NUMBER if it hits
MAX_MEDIA_PORT_NUMBER?

When ICE is in use, MAX_MEDIA_PORT_NUMBER will mostly be ignored.
Otherwise (e.g. SIP calls), it is taken into account and Jitsi will
"cycle" through the range. We do not have current plans to modify that
behavior in the near future.


#11

Hello Emil,

I definitely did not want to imply (I also think, that I did not do so.) that one should disable Jingle relay nodes to use port forwarding. I never ever had any problems connecting with Jingle relay nodes. The point just is that I prefer not to depend on Jingle relay nodes for reasons of bandwidth consumption and their support not being that widespread. (I also have problems reaching users of other Jabber servers through my jit.si account... So this is no universal cure as well at the moment... But this is supposed to be in beta anyway...)

What I meant by strict is that normally I would expect ICE to punch a hole through the firewall by beginning with some outbound traffic so that incoming traffic by the remote party is accepted. But this just did not happen. I suspect that this is more a problem of our routers than of Jitsi, so that's what I meant by low quality of consumer-grade routers. (My router is most probably doing at least some kind of symmetric NAT, but shouldn't ICE handle this as well as it always checks for ADDR:PORT combinations?)

Regards, Adam.

···

Am 07.08.2011, 21:03 Uhr, schrieb Emil Ivov <emcho@jitsi.org>:

Hey Adam, all,

On 7 août 2011, at 20:23, "Adam Reichold" <adamreichold@myopera.com> > wrote:

What type of problem was cured:

I'd like to comment on this since I find it a bit misleading and fear it may be confusong to some users. No real problem is solved by disabling Jingle Nodes or at least not in the scenario you describe.

If you were still able to call your friend after disconnecting accounts that had JN support, then your friend's contact was simply on a network that didn't have that support. Disabling the said accounts hence only allowed to make sure the traffic didn't use a relay, it didn't solve any connectivity problems.

I want this to be clear because I am afraid people might draw the wrong conclusions from this recount and assume they need to disable JN and do port forwarding if they want reliable connectivity. This is not the case!

A bit more below:

I have one friend who used a configuration such that ingoing and outgoing calls between would always fail due to an "ICE failure". We are both using DSL lines and are sitting behind consumer-grade routers. The log files indicate that while STUN discovery of public IP adresses worked, the firewall of our routers were quite strict about UDP traffic.

Exactly what do you mean by strict? If STUN discovery worked but ICE then failed, this most probably meant that your NAT (or that of your friend) was allocating ports in an endpoint dependent manner (this is commonly referred to as a symmetric NAT). Successfully using STUN (with ICE) is completely compatible with "strict" firewalls that only allow inbound packets after first seeing an outbound one in the exactly opposite direction.

Cheers,
Emil

We were able to establish connections by activating UPnP on his side but he considers it a security problem and my router does not even support UPnP. (Well it is disabled in the firmware by the manufacturer again for security reasons.) Therefore I set up manual port forwarding of UDP traffic in a certain quite narrow port range on my router and with ICE using those ports we could again establish a connection. (I needed different than default ports because I did not want to open 1000 ports and because there are several computers on my network which get different port ranges forwarded to them.)

I think in the end the problem is the lousy quality of (and the limit of amount of control over) those consumer-grade routers, but getting ICE to use specific ports which I manually forwarded so that I do not need to rely on the stateful filtering of the firewall of my router. I hope this helps to explain what we did in this specific case. (I have a lot of other people behind DSL routers that I do not have any connection problems with...) But feel free to inquire if you need more details.

Regards, Adam.

P.S.: One could probably argue that opening 32 ports isn't necessarily more secure than opening 3200 ports especially if there is no service configured to continually listen on these ports anyway. But maybe being paranoid about opening ports to the internet isn't the worst one could do... What do you think?

Am 05.08.2011, 20:47 Uhr, schrieb Earl <Large.Files@gmx.net>:

Hi Adam,

would you please explain in more detail what exactly helped you with
some of your connectivity problems? What did you do so that two people
can now be reached without using a Jingle relay?

How do you observe whether or not Jingle node relay is being used or
not?

Regards, Earl

On 8/2/2011 8:56 AM, Adam Reichold wrote:

Thank you for the clarification. I should make some headroom then...

By the way, this really seemed to have helped with some of my
connectivity problems. There are at least two people which I can call
now without using a Jingle relay and could not do so before the change.

Am 01.08.2011, 21:39 Uhr, schrieb Lyubomir Marinov <lubo@jitsi.org>:

On Wed, Jul 27, 2011 at 10:21 AM, Adam Reichold >>>>> <adamreichold@myopera.com> wrote:

One last question: For security concerns, I'd like to make the
forwarded
port range as small as possible. Will Jitsi cycle through the
configured
range, i.e. will it restart at MIN_MEDIA_PORT_NUMBER if it hits
MAX_MEDIA_PORT_NUMBER?

When ICE is in use, MAX_MEDIA_PORT_NUMBER will mostly be ignored.
Otherwise (e.g. SIP calls), it is taken into account and Jitsi will
"cycle" through the range. We do not have current plans to modify that
behavior in the near future.


#12

Hello Emil,

One more clarification then: your bandwidth consumption is in no way affected by Jingle Nodes. Use of JN only has an impact on the bandwidth consumption of your service provider ... but that's for them to consider.

It is exactly your bandwidth I do consider especially for a free service. I mean, I have all this unused bandwidth that I'm paying my ISP for and than someone on the net has to duplicate it because my router sucks? That sucks! I just try to enforce endpoint-to-endpoint here... Even though with little luck. :-\ (And of course this router is lent to me by that same ISP who just happens to sell SIP services as well...)

I must have missed your report on that one. My jit.si account has contacts on gmail, jabber.org and other servers and we haven't really noticed any interop problems. Whic networks have you seen problems with?

I have not reported it yet, because I thought that you will probably change your configuration quite often in the near future anyway. Well so here is the report: When I add peers from a different server to my jit.si account (In my case the would be users of jabber.org and jabber.ccc.de, but also gabble.echo@test.collabora.co.uk did not do the trick.), the authorization request never seems to hit them. Therefore I suspected, that you just have not enabled federation yet which obviously by now is not the case. (The problem is probably reproduced by at least of my friends, but I have to check on that before confirming anything...)

as it always checks for ADDR:PORT combinations?)

Didn't get this part.

Ok, sorry, confused that one: I thought that because STUN will discover the outside address and port, my peer will know about the unique outside port even it is endpoint dependent. But of course, he will know the unique port for the STUN server which is not very helpful at all... (There is no way to get around this without relays or static forwarding, is there? Well, this sucks as well...)

Care to attach the logs of such a session?

Guess I have some log creation to do... But this will probably take to the middle of the coming week as I have to recruit the corresponding "endpoints" again.

Regards, Adam.

P.S.: Sorry for the derailings of my language. I hope nobody minds.