[sip-comm-dev] Jingle Call Failed


#1

Hi,

I tried to call someone behind NAT- so ICE would come into play. Unfortunately it failed both ways with the strange error message "address already in use". Please see the log attached.

I was connected twice - on cable and on WLAN (192.168.1.2 and .3) - ICE discovered it. But can this be the cause?

Conrad

jingle_call.log (47 KB)


#2

Hi Conrad,

···

2010/12/7 <conrad_videokonferenz@gmx.de>

Hi,

I tried to call someone behind NAT- so ICE would come into play.
Unfortunately it failed both ways with the strange error message "address
already in use". Please see the log attached.

I was connected twice - on cable and on WLAN (192.168.1.2 and .3) - ICE
discovered it. But can this be the cause?

I will test a similar setup (laptop connected with two address in same
subnet) tomorrow. But does it work when you disconnect one of your
interfaces (WLAN or cable) ?

It may be also that another program(s) is binded to port 5026 to 5028, but
if so it is big coincidence...

Regards,
--
Seb

Conrad

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


#3

Hey folks,

I tried to call someone behind NAT- so ICE would come into play.

Oh, ICE always comes into play with Jingle. Regardless of NAT type or
network configuration.

"No assumptions", as Jonathan Rosenberg used to say.

Unfortunately it failed both ways with the strange error message "address
already in use". Please see the log attached.

I was connected twice - on cable and on WLAN (192.168.1.2 and .3) - ICE
discovered it. But can this be the cause?

Could be. Not sure though.

It may be also that another program(s) is binded to port 5026 to 5028, but
if so it is big coincidence...

Nah. ice4j is supposed to try 50 consecutive ports unless we configure
it otherwise so if only 5026 and 5028 are taken, then it should simply
move to the next. We need to check why it isn't doing so.

We'll discuss this tomorrow.

Cheers,
Emil

···

On Tue, Dec 7, 2010 at 10:08 PM, Sebastien Vincent <seb@sip-communicator.org> wrote:


#4

Hi Conrad, Emil,

Conrad, I see in your logs that you used stun.gmx.de as your STUN server. I give it a try and I get no Binding response or error from this server. I suspect stun.gmx.de implements "old" STUN RFC3489. As you get no response, peers do not know your server reflexive address and so perform only check with your private IP address (that will failed ICE).

So you could do the following, find a STUN server that implements "new" STUN RFC5389 and replace stun.gmx.de with this one or remove any STUN server you have added in configuration form and be sure to check "Use SIP Communicator's STUN server in case...". The SIP Communicator's STUN server implements RFC5389 (it is the one we use daily).

Regards,

···

--
Seb

Le 07/12/2010 22:58, Emil Ivov a �crit :

Hey folks,

On Tue, Dec 7, 2010 at 10:08 PM, Sebastien Vincent > <seb@sip-communicator.org> wrote:
   

I tried to call someone behind NAT- so ICE would come into play.
       

Oh, ICE always comes into play with Jingle. Regardless of NAT type or
network configuration.

"No assumptions", as Jonathan Rosenberg used to say.

Unfortunately it failed both ways with the strange error message "address
already in use". Please see the log attached.

I was connected twice - on cable and on WLAN (192.168.1.2 and .3) - ICE
discovered it. But can this be the cause?
       

Could be. Not sure though.

It may be also that another program(s) is binded to port 5026 to 5028, but
if so it is big coincidence...
     

Nah. ice4j is supposed to try 50 consecutive ports unless we configure
it otherwise so if only 5026 and 5028 are taken, then it should simply
move to the next. We need to check why it isn't doing so.

We'll discuss this tomorrow.

Cheers,
Emil

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

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


#5

Le 08/12/2010 09:10, Sebastien Vincent a �crit :

Hi Conrad, Emil,

Conrad, I see in your logs that you used stun.gmx.de as your STUN server. I give it a try and I get no Binding response or error from this server. I suspect stun.gmx.de implements "old" STUN RFC3489. As you get no response, peers do not know your server reflexive address and so perform only check with your private IP address (that will failed ICE).

So you could do the following, find a STUN server that implements "new" STUN RFC5389 and replace stun.gmx.de with this one or remove any STUN server you have added in configuration form and be sure to check "Use SIP Communicator's STUN server in case...". The SIP Communicator's STUN server implements RFC5389 (it is the one we use daily).

In fact, the logs indicate that the STUN server (stun.gmx.de) has been auto detected. So you can add a STUN server manually. If you don't know any, try stun.jitsi.net on port 3478.

···

--
Seb

Regards,
--
Seb

Le 07/12/2010 22:58, Emil Ivov a �crit :

Hey folks,

On Tue, Dec 7, 2010 at 10:08 PM, Sebastien Vincent >> <seb@sip-communicator.org> wrote:

I tried to call someone behind NAT- so ICE would come into play.

Oh, ICE always comes into play with Jingle. Regardless of NAT type or
network configuration.

"No assumptions", as Jonathan Rosenberg used to say.

Unfortunately it failed both ways with the strange error message "address
already in use". Please see the log attached.

I was connected twice - on cable and on WLAN (192.168.1.2 and .3) - ICE
discovered it. But can this be the cause?

Could be. Not sure though.

It may be also that another program(s) is binded to port 5026 to 5028, but
if so it is big coincidence...

Nah. ice4j is supposed to try 50 consecutive ports unless we configure
it otherwise so if only 5026 and 5028 are taken, then it should simply
move to the next. We need to check why it isn't doing so.

We'll discuss this tomorrow.

Cheers,
Emil

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

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