[sip-comm] Why the DNS lookup of stun.iptel.org?


#1

I am using SIP Communicator for P2P testing. No NATs, as I am only using IPv6. Yet I see DNS lookups (Query types 28 and 1) for stun.iptel.org.

I cannot find any option for controlling what STUN servers are used. How do I disable this.

Also I would like to turn off IPv4 entirely, can this be done?

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#2

Hey Robert,

Robert Moskowitz wrote:

I am using SIP Communicator for P2P testing. No NATs, as I am only
using IPv6. Yet I see DNS lookups (Query types 28 and 1) for
stun.iptel.org.

We us the "stun.iptel.org" address only as a sample address of something
that we know is on the Internet. We need this as a last resort in some
cases where we can't determine which local address we should be using so
we try to detect the one that would take us to our sample public address.

I agree it's not quite elegant. Is this causing any problems for you?

I cannot find any option for controlling what STUN servers are used.
How do I disable this.

Also I would like to turn off IPv4 entirely, can this be done?

Try removing any IPv4 addresses from your interfaces. This should do it.

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#3

Emil Ivov wrote:

Hey Robert,

Robert Moskowitz wrote:
  

I am using SIP Communicator for P2P testing. No NATs, as I am only using IPv6. Yet I see DNS lookups (Query types 28 and 1) for stun.iptel.org.
    
We us the "stun.iptel.org" address only as a sample address of something
that we know is on the Internet. We need this as a last resort in some
cases where we can't determine which local address we should be using so
we try to detect the one that would take us to our sample public address.

I agree it's not quite elegant. Is this causing any problems for you?
  
Well, of course this is going to fail for me, as they only have an IPv4 address. STUN does not make much sense in a strickly IPv6 environment. I want to turn STUN off completely, but there is no dialog that shows the STUN servers. It least where I have looked. There is the Advanced feature for SIP accounts to specify a proxy, but not really the same thing...

So of course I have to wait for the timeout of looking up an IPv4 address...

I cannot find any option for controlling what STUN servers are used. How do I disable this.

Also I would like to turn off IPv4 entirely, can this be done?
    
Try removing any IPv4 addresses from your interfaces. This should do it.

First you cannot remove IPv4 from l0, so you always have IPv4 in the kernel. It is too baked into Linux.

Then I am working with the HIPL implementation of the HIP protocol for security and mobility. I am storing the HIP HI records in my DNS along with the AAAA records, and using the hipdnsproxy app to allow 'legacy' (read non-HIP aware) apps to run over HIP. Thing is that hipdnsproxy will not only generate the HIT from the HI RR and pass that on to the app so that an IPv6 app is fat and happy and not even know it is running over HIP (A HIT is an ORCHID IPv6 address), hipdnsproxy also generates an LSI from the HI RR so that IPv4 apps (like TightVNC) will work over HIP over IPv6.

This means that even though the source and target hosts do not have routable IPv4 addresses, they have 'Local Scope Identities' that an IPv4 app believes are IPv4 address (in fact the HIPL code uses addresses like 1.0.0.4 as a destination address with 1.0.0.1 as the source address). So an app that is both IPv4 and IPv6 and tries IPv4 first will use the LSI shim when I want it to use HITs and work as an IPv6 app. So I look for a 'switch' in an app to force it to use IPv6 and ignore any IPv4 addresses.

For more on HIP and the HIPL implementation see infrahip.hiit.fi. For the manual see infrahip.hiit.fi/hipl/manual/index.html, and for information on hipdnsproxy see ch 30 & 31.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#4

Robert Moskowitz wrote:

Well, of course this is going to fail for me, as they only have an IPv4
address. STUN does not make much sense in a strickly IPv6 environment.
I want to turn STUN off completely, but there is no dialog that shows the
STUN servers. It least where I have looked. There is the Advanced
feature for SIP accounts to specify a proxy, but not really the same
thing...

So of course I have to wait for the timeout of looking up an IPv4 address...

I did not explain myself clearly, my bad.

We are not using STUN (not unless you explicitly enable it by setting
the STUN_SERVER_ADDRESS config property). We are not even contacting the
stun.iptel.org host in any way. We were simply planning on maybe using
it one day as an example of an Internet connected host. This is now
deprecated as we have better, destination dependent mechanisms for local
address selection. (that's the part I missed in my previous mail)

Therefore, the only thing that you are probably having a problem with is
that once you start the application you'll have to wait for the DNS
query to expire before being able to use the NetworkAddressManager, or
in other words, before being able to actually make a call. Note that
this would only happen if you have a DNS server that is not responding.
Is this your case?

Anyways, that's an easy fix. The code is a vestige of previous
intentions and it's completely disposable. I can fix it next week if you
could open an entry in our issue tracker.

I cannot find any option for controlling what STUN servers are used.
How do I disable this.

Also I would like to turn off IPv4 entirely, can this be done?
    

Try removing any IPv4 addresses from your interfaces. This should do it.

First you cannot remove IPv4 from l0, so you always have IPv4 in the
kernel. It is too baked into Linux.

True, but that one wouldn't have been a problem anyway.

Then I am working with the HIPL implementation of the HIP protocol for
security and mobility. I am storing the HIP HI records in my DNS along
with the AAAA records, and using the hipdnsproxy app to allow 'legacy'
(read non-HIP aware) apps to run over HIP. Thing is that hipdnsproxy
will not only generate the HIT from the HI RR and pass that on to the
app so that an IPv6 app is fat and happy and not even know it is running
over HIP (A HIT is an ORCHID IPv6 address), hipdnsproxy also generates
an LSI from the HI RR so that IPv4 apps (like TightVNC) will work over
HIP over IPv6.

This means that even though the source and target hosts do not have
routable IPv4 addresses, they have 'Local Scope Identities' that an IPv4
app believes are IPv4 address (in fact the HIPL code uses addresses like
1.0.0.4 as a destination address with 1.0.0.1 as the source address). So
an app that is both IPv4 and IPv6 and tries IPv4 first will use the LSI
shim when I want it to use HITs and work as an IPv6 app. So I look for a
'switch' in an app to force it to use IPv6 and ignore any IPv4 addresses.

OK, then in this case all you need to do is to specify that you'd prefer
to try AAAA DNS resolution before going for IPv4. There's a java
property that allows you to do this:

java.net.preferIPv6Address

If you are running SC from one of the installation packages then you'd
need to modify your sip-communicator.sh file. On the line that actually
executes SC, add

-Djava.net.preferIPv6Addresses=true

somewhere before "net.java.sip.communicator.launcher.SIPCommunicator".
You'll see other similar properties being set there so just paste it
between two of them.

If you are running from sources, then simply grep for the following in
the build.xml file:

            <sysproperty key="java.net.preferIPv6Addresses"
                value="false"/>

and change it to:

            <sysproperty key="java.net.preferIPv6Addresses"
                value="true"/>

Hope this helps
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#5

Emil Ivov wrote:

Robert Moskowitz wrote:
  

Well, of course this is going to fail for me, as they only have an IPv4 address. STUN does not make much sense in a strickly IPv6 environment.
I want to turn STUN off completely, but there is no dialog that shows the STUN servers. It least where I have looked. There is the Advanced feature for SIP accounts to specify a proxy, but not really the same thing...

So of course I have to wait for the timeout of looking up an IPv4 address...
    
I did not explain myself clearly, my bad.

We are not using STUN (not unless you explicitly enable it by setting
the STUN_SERVER_ADDRESS config property). We are not even contacting the
stun.iptel.org host in any way. We were simply planning on maybe using
it one day as an example of an Internet connected host. This is now
deprecated as we have better, destination dependent mechanisms for local
address selection. (that's the part I missed in my previous mail)

Therefore, the only thing that you are probably having a problem with is
that once you start the application you'll have to wait for the DNS
query to expire before being able to use the NetworkAddressManager, or
in other words, before being able to actually make a call. Note that
this would only happen if you have a DNS server that is not responding.
Is this your case?

Anyways, that's an easy fix. The code is a vestige of previous
intentions and it's completely disposable. I can fix it next week if you
could open an entry in our issue tracker.

I cannot find any option for controlling what STUN servers are used. How do I disable this.

Also I would like to turn off IPv4 entirely, can this be done?
    

Try removing any IPv4 addresses from your interfaces. This should do it.
      

First you cannot remove IPv4 from l0, so you always have IPv4 in the kernel. It is too baked into Linux.
    
True, but that one wouldn't have been a problem anyway.
  
Then I am working with the HIPL implementation of the HIP protocol for security and mobility. I am storing the HIP HI records in my DNS along with the AAAA records, and using the hipdnsproxy app to allow 'legacy' (read non-HIP aware) apps to run over HIP. Thing is that hipdnsproxy will not only generate the HIT from the HI RR and pass that on to the app so that an IPv6 app is fat and happy and not even know it is running over HIP (A HIT is an ORCHID IPv6 address), hipdnsproxy also generates an LSI from the HI RR so that IPv4 apps (like TightVNC) will work over HIP over IPv6.

This means that even though the source and target hosts do not have routable IPv4 addresses, they have 'Local Scope Identities' that an IPv4 app believes are IPv4 address (in fact the HIPL code uses addresses like 1.0.0.4 as a destination address with 1.0.0.1 as the source address). So an app that is both IPv4 and IPv6 and tries IPv4 first will use the LSI shim when I want it to use HITs and work as an IPv6 app. So I look for a 'switch' in an app to force it to use IPv6 and ignore any IPv4 addresses.
    
OK, then in this case all you need to do is to specify that you'd prefer
to try AAAA DNS resolution before going for IPv4. There's a java
property that allows you to do this:

java.net.preferIPv6Address

If you are running SC from one of the installation packages then you'd
need to modify your sip-communicator.sh file. On the line that actually
executes SC, add

-Djava.net.preferIPv6Addresses=true

somewhere before "net.java.sip.communicator.launcher.SIPCommunicator".
You'll see other similar properties being set there so just paste it
between two of them.
  
I am running it in Centos 5.2, using the Fedora rpm from http://download.sip-communicator.org/nightly/fedora/

So I found a file /usr/bin/sip-communicator that looked like the right place and in it a line starting with:

COMMAND="$javabin

That had the -D entries. So I added parameter you supplied there. When I started sip-communicator from the gnome panel I got an error. A dialog box stating:

An error occured while logging in with account: Usernaem: oqo1, Server name: null. This is most probably an internal application error. You could report your problem to issues@sip-communicator.dev.java.net.

So obviously I don't got it yet...

···

If you are running from sources, then simply grep for the following in
the build.xml file:

            <sysproperty key="java.net.preferIPv6Addresses"
                value="false"/>

and change it to:

            <sysproperty key="java.net.preferIPv6Addresses"
                value="true"/>

Hope this helps
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#6

Hey Robert,

Just a quick note to let you know that we've fixed this today and will
commit tomorrow morning.

Cheers
Emil

Robert Moskowitz wrote:

···

Emil Ivov wrote:

Robert Moskowitz wrote:
  

Well, of course this is going to fail for me, as they only have an IPv4
address. STUN does not make much sense in a strickly IPv6 environment.
I want to turn STUN off completely, but there is no dialog that shows the
STUN servers. It least where I have looked. There is the Advanced
feature for SIP accounts to specify a proxy, but not really the same
thing...

So of course I have to wait for the timeout of looking up an IPv4 address...
    

I did not explain myself clearly, my bad.

We are not using STUN (not unless you explicitly enable it by setting
the STUN_SERVER_ADDRESS config property). We are not even contacting the
stun.iptel.org host in any way. We were simply planning on maybe using
it one day as an example of an Internet connected host. This is now
deprecated as we have better, destination dependent mechanisms for local
address selection. (that's the part I missed in my previous mail)

Therefore, the only thing that you are probably having a problem with is
that once you start the application you'll have to wait for the DNS
query to expire before being able to use the NetworkAddressManager, or
in other words, before being able to actually make a call. Note that
this would only happen if you have a DNS server that is not responding.
Is this your case?

Anyways, that's an easy fix. The code is a vestige of previous
intentions and it's completely disposable. I can fix it next week if you
could open an entry in our issue tracker.

I cannot find any option for controlling what STUN servers are used.
How do I disable this.

Also I would like to turn off IPv4 entirely, can this be done?
    

Try removing any IPv4 addresses from your interfaces. This should do it.
      

First you cannot remove IPv4 from l0, so you always have IPv4 in the
kernel. It is too baked into Linux.
    

True, but that one wouldn't have been a problem anyway.
  

Then I am working with the HIPL implementation of the HIP protocol for
security and mobility. I am storing the HIP HI records in my DNS along
with the AAAA records, and using the hipdnsproxy app to allow 'legacy'
(read non-HIP aware) apps to run over HIP. Thing is that hipdnsproxy
will not only generate the HIT from the HI RR and pass that on to the
app so that an IPv6 app is fat and happy and not even know it is running
over HIP (A HIT is an ORCHID IPv6 address), hipdnsproxy also generates
an LSI from the HI RR so that IPv4 apps (like TightVNC) will work over
HIP over IPv6.

This means that even though the source and target hosts do not have
routable IPv4 addresses, they have 'Local Scope Identities' that an IPv4
app believes are IPv4 address (in fact the HIPL code uses addresses like
1.0.0.4 as a destination address with 1.0.0.1 as the source address). So
an app that is both IPv4 and IPv6 and tries IPv4 first will use the LSI
shim when I want it to use HITs and work as an IPv6 app. So I look for a
'switch' in an app to force it to use IPv6 and ignore any IPv4 addresses.
    

OK, then in this case all you need to do is to specify that you'd prefer
to try AAAA DNS resolution before going for IPv4. There's a java
property that allows you to do this:

java.net.preferIPv6Address

If you are running SC from one of the installation packages then you'd
need to modify your sip-communicator.sh file. On the line that actually
executes SC, add

-Djava.net.preferIPv6Addresses=true

somewhere before "net.java.sip.communicator.launcher.SIPCommunicator".
You'll see other similar properties being set there so just paste it
between two of them.
  
I am running it in Centos 5.2, using the Fedora rpm from
http://download.sip-communicator.org/nightly/fedora/

So I found a file /usr/bin/sip-communicator that looked like the right
place and in it a line starting with:

COMMAND="$javabin

That had the -D entries. So I added parameter you supplied there. When I
started sip-communicator from the gnome panel I got an error. A dialog
box stating:

An error occured while logging in with account: Usernaem: oqo1, Server
name: null. This is most probably an internal application error. You
could report your problem to issues@sip-communicator.dev.java.net.

So obviously I don't got it yet...

If you are running from sources, then simply grep for the following in
the build.xml file:

            <sysproperty key="java.net.preferIPv6Addresses"
                value="false"/>

and change it to:

            <sysproperty key="java.net.preferIPv6Addresses"
                value="true"/>

Hope this helps
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#7

Emil Ivov wrote:

Hey Robert,

Just a quick note to let you know that we've fixed this today and will
commit tomorrow morning.
  
I hope by 'fixed' you mean specifying the PreferIPv6 value.

···

Robert Moskowitz wrote:
  

Emil Ivov wrote:
    

Robert Moskowitz wrote:
  

Well, of course this is going to fail for me, as they only have an IPv4 address. STUN does not make much sense in a strickly IPv6 environment.
I want to turn STUN off completely, but there is no dialog that shows the STUN servers. It least where I have looked. There is the Advanced feature for SIP accounts to specify a proxy, but not really the same thing...

So of course I have to wait for the timeout of looking up an IPv4 address...
    

I did not explain myself clearly, my bad.

We are not using STUN (not unless you explicitly enable it by setting
the STUN_SERVER_ADDRESS config property). We are not even contacting the
stun.iptel.org host in any way. We were simply planning on maybe using
it one day as an example of an Internet connected host. This is now
deprecated as we have better, destination dependent mechanisms for local
address selection. (that's the part I missed in my previous mail)

Therefore, the only thing that you are probably having a problem with is
that once you start the application you'll have to wait for the DNS
query to expire before being able to use the NetworkAddressManager, or
in other words, before being able to actually make a call. Note that
this would only happen if you have a DNS server that is not responding.
Is this your case?

Anyways, that's an easy fix. The code is a vestige of previous
intentions and it's completely disposable. I can fix it next week if you
could open an entry in our issue tracker.

I cannot find any option for controlling what STUN servers are used. How do I disable this.

Also I would like to turn off IPv4 entirely, can this be done?
    

Try removing any IPv4 addresses from your interfaces. This should do it.
      

First you cannot remove IPv4 from l0, so you always have IPv4 in the kernel. It is too baked into Linux.
    

True, but that one wouldn't have been a problem anyway.
  

Then I am working with the HIPL implementation of the HIP protocol for security and mobility. I am storing the HIP HI records in my DNS along with the AAAA records, and using the hipdnsproxy app to allow 'legacy' (read non-HIP aware) apps to run over HIP. Thing is that hipdnsproxy will not only generate the HIT from the HI RR and pass that on to the app so that an IPv6 app is fat and happy and not even know it is running over HIP (A HIT is an ORCHID IPv6 address), hipdnsproxy also generates an LSI from the HI RR so that IPv4 apps (like TightVNC) will work over HIP over IPv6.

This means that even though the source and target hosts do not have routable IPv4 addresses, they have 'Local Scope Identities' that an IPv4 app believes are IPv4 address (in fact the HIPL code uses addresses like 1.0.0.4 as a destination address with 1.0.0.1 as the source address). So an app that is both IPv4 and IPv6 and tries IPv4 first will use the LSI shim when I want it to use HITs and work as an IPv6 app. So I look for a 'switch' in an app to force it to use IPv6 and ignore any IPv4 addresses.
    

OK, then in this case all you need to do is to specify that you'd prefer
to try AAAA DNS resolution before going for IPv4. There's a java
property that allows you to do this:

java.net.preferIPv6Address

If you are running SC from one of the installation packages then you'd
need to modify your sip-communicator.sh file. On the line that actually
executes SC, add

-Djava.net.preferIPv6Addresses=true

somewhere before "net.java.sip.communicator.launcher.SIPCommunicator".
You'll see other similar properties being set there so just paste it
between two of them.
  

I am running it in Centos 5.2, using the Fedora rpm from http://download.sip-communicator.org/nightly/fedora/

So I found a file /usr/bin/sip-communicator that looked like the right place and in it a line starting with:

COMMAND="$javabin

That had the -D entries. So I added parameter you supplied there. When I started sip-communicator from the gnome panel I got an error. A dialog box stating:

An error occured while logging in with account: Usernaem: oqo1, Server name: null. This is most probably an internal application error. You could report your problem to issues@sip-communicator.dev.java.net.

So obviously I don't got it yet...
    

If you are running from sources, then simply grep for the following in
the build.xml file:

            <sysproperty key="java.net.preferIPv6Addresses"
                value="false"/>

and change it to:

            <sysproperty key="java.net.preferIPv6Addresses"
                value="true"/>

Hope this helps
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#8

I am seeing part of my problem via wireshark; IPCMPv6 port unreachable (admin prohibited). And then my system locks up hard requiring a hard reboot, so I can't see what port the RTP or other package was using.

I do allow UDP 5060. I have not done any advanced configurations for serverless SIP accounts on both systems.

So what ports do I need to allow?

And protocols...

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#9

Hey Robert,

Robert Moskowitz wrote:

I hope by 'fixed' you mean specifying the PreferIPv6 value.

No, by 'fixed' I meant the 'Why the DNS lookup of stun.iptel.org?' or in
other words - issue #596 that describes the DNS query for
stun.iptel.org. We'll commit it tomorrow (Friday).

I've just managed to reproduce the problem that occurs with
ReigstrarLess accounts when you set the preferIPv6Addresses value to
true. Shouldn't be hard to handle.

Could you please add another issue for this one? We'll fix it as our
time permits.

Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#10

Hey Robert,

You shouldn't specifically allow any ports, I am currently working on
the "port unreachable" issue. Will post as soon as it is resolved.

Cheers
Emil

Robert Moskowitz wrote:

···

I am seeing part of my problem via wireshark; IPCMPv6 port unreachable
(admin prohibited). And then my system locks up hard requiring a hard
reboot, so I can't see what port the RTP or other package was using.

I do allow UDP 5060. I have not done any advanced configurations for
serverless SIP accounts on both systems.

So what ports do I need to allow?

And protocols...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#11

Emil Ivov wrote:

Hey Robert,

You shouldn't specifically allow any ports, I am currently working on
the "port unreachable" issue. Will post as soon as it is resolved.
  
In otherwords, I cannot use SIP Communicator until then. I have to allow at least UDP 5060, as that is the port for SIP UDP, and at least some of the RTP flows. There is something else RTP going over other ports. So if I don't allow even 5060 in ip6tables, nothing will happen.

Sigh.

···

Cheers
Emil

Robert Moskowitz wrote:
  

I am seeing part of my problem via wireshark; IPCMPv6 port unreachable (admin prohibited). And then my system locks up hard requiring a hard reboot, so I can't see what port the RTP or other package was using.

I do allow UDP 5060. I have not done any advanced configurations for serverless SIP accounts on both systems.

So what ports do I need to allow?

And protocols...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#12

Emil Ivov wrote:

Hey Robert,

You shouldn't specifically allow any ports, I am currently working on
the "port unreachable" issue. Will post as soon as it is resolved.
  
So far I identified you use UDP ports:

5060 sip
5000 rtcp 'Real Time Control Protocol' according to wireshark
5001 rtp the actual voice flow.

···

Cheers
Emil

Robert Moskowitz wrote:
  

I am seeing part of my problem via wireshark; IPCMPv6 port unreachable (admin prohibited). And then my system locks up hard requiring a hard reboot, so I can't see what port the RTP or other package was using.

I do allow UDP 5060. I have not done any advanced configurations for serverless SIP accounts on both systems.

So what ports do I need to allow?

And protocols...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#13

Hey Robert,

Robert Moskowitz wrote:

Emil Ivov wrote:

Hey Robert,

You shouldn't specifically allow any ports, I am currently working on
the "port unreachable" issue. Will post as soon as it is resolved.
  
So far I identified you use UDP ports:

5060 sip

Yup, that's the port we try by default and the one we use if it is free.

5000 rtcp 'Real Time Control Protocol' according to wireshark
5001 rtp the actual voice flow.

When we allocate ports for RTP we start indeed with 5000 and 5001 for
rtp and rtcp respectively, and then move up until we manage to get a
binding. The first pair goes to audio and then we repeat the procedure
for a pair of video ports. We do this for the 5000-6000 range.

Once again though, I am a bit surprised that you actually need to allow
them on your firewall. I am not very familiar with CentOS but the
default configurations for most OSes (and all linux distros I've worked
with) would authorize incoming packets on ports that you've already used
to send from. So unless you've specifically modified your network
configuration you probably don't need to worry about opening ports.

I did manage to reproduce the "port unreachable" error that you reported
in one of your previous mails and I am taking care of it (with a bit of
a lag though since we are currently concentrating on our GSoC application).

Cheers
Emil

Once again, though,

···

Cheers
Emil

Robert Moskowitz wrote:
  

I am seeing part of my problem via wireshark; IPCMPv6 port unreachable
(admin prohibited). And then my system locks up hard requiring a hard
reboot, so I can't see what port the RTP or other package was using.

I do allow UDP 5060. I have not done any advanced configurations for
serverless SIP accounts on both systems.

So what ports do I need to allow?

And protocols...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#14

Emil Ivov wrote:

Hey Robert,

Robert Moskowitz wrote:
  

Emil Ivov wrote:
    

Hey Robert,

You shouldn't specifically allow any ports, I am currently working on
the "port unreachable" issue. Will post as soon as it is resolved.
  

So far I identified you use UDP ports:

5060 sip
    
Yup, that's the port we try by default and the one we use if it is free.

5000 rtcp 'Real Time Control Protocol' according to wireshark
5001 rtp the actual voice flow.
    
When we allocate ports for RTP we start indeed with 5000 and 5001 for
rtp and rtcp respectively, and then move up until we manage to get a
binding. The first pair goes to audio and then we repeat the procedure
for a pair of video ports. We do this for the 5000-6000 range.
  

Good to know.

Once again though, I am a bit surprised that you actually need to allow
them on your firewall. I am not very familiar with CentOS but the
default configurations for most OSes (and all linux distros I've worked
with) would authorize incoming packets on ports that you've already used
to send from.

I will have to check into this, but think for a moment. That first UDP packet on port 5000, may open the source to recieve on it, but what about the destination? It has not recieved anything on port 5000, so that is blocked unless specifically allowed in iptables and/or ip6tables. Granted I am not an expert on iptables and ip6tables, but I have worked with them for some time and this is how I have had to fight with them.

So unless you've specifically modified your network
configuration you probably don't need to worry about opening ports.
  
Not my experience.

I did manage to reproduce the "port unreachable" error that you reported
in one of your previous mails and I am taking care of it (with a bit of
a lag though since we are currently concentrating on our GSoC application).
  
Knowing which ports to allow takes care of it.

···

Cheers
Emil

Once again, though,
  

Cheers
Emil

Robert Moskowitz wrote:
  

I am seeing part of my problem via wireshark; IPCMPv6 port unreachable (admin prohibited). And then my system locks up hard requiring a hard reboot, so I can't see what port the RTP or other package was using.

I do allow UDP 5060. I have not done any advanced configurations for serverless SIP accounts on both systems.

So what ports do I need to allow?

And protocols...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#15

Robert Moskowitz wrote:

Once again though, I am a bit surprised that you actually need to allow
them on your firewall. I am not very familiar with CentOS but the
default configurations for most OSes (and all linux distros I've worked
with) would authorize incoming packets on ports that you've already used
to send from.

I will have to check into this, but think for a moment. That first UDP
packet on port 5000, may open the source to recieve on it, but what
about the destination?

Same thing goes for the destination. If it hadn't already sent a packet
then this one would indeed be dropped. But as soon as it also sends even
a single datagram, it would also be open for reception.

Note that both parties start streaming packets regardless of what
happens to them at the destination. Therefore, at one point they would
have both opened holes in their firewalls and hence they would both
start receiving. True - a few packets would be lost but this is not
really a problem in most cases.

The reason why IPv6 packets in SC would get dropped in the latest
version is simply the fact that for some reason we don't seem to be
listening on our IPv6 address. The operating system detects this and
sends port unreachable packets in reply.

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#16

Hey Robert,

Most of the issues should be ok in the latest release, so you could give
it a try when you have a minute.

Let us know if other problems arise.

Cheers
Emil

Emil Ivov wrote:

···

Robert Moskowitz wrote:

Once again though, I am a bit surprised that you actually need to allow
them on your firewall. I am not very familiar with CentOS but the
default configurations for most OSes (and all linux distros I've worked
with) would authorize incoming packets on ports that you've already used
to send from.

I will have to check into this, but think for a moment. That first UDP
packet on port 5000, may open the source to recieve on it, but what
about the destination?

Same thing goes for the destination. If it hadn't already sent a packet
then this one would indeed be dropped. But as soon as it also sends even
a single datagram, it would also be open for reception.

Note that both parties start streaming packets regardless of what
happens to them at the destination. Therefore, at one point they would
have both opened holes in their firewalls and hence they would both
start receiving. True - a few packets would be lost but this is not
really a problem in most cases.

The reason why IPv6 packets in SC would get dropped in the latest
version is simply the fact that for some reason we don't seem to be
listening on our IPv6 address. The operating system detects this and
sends port unreachable packets in reply.

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net