jitsi/ice4j

A Java implementation of the ICE protocol

Jitsi Desktop

Jitsi Desktop is a free open-source audio/video and chat communicator that supports protocols such as SIP, XMPP/Jabber, IRC and many other useful features.

Please do not confuse this project with Jitsi Meet, the online video conferencing solution with a free instance at https://meet.jit.si.

Support

Jitsi Desktop is the heritage of Jitsi Meet. While some components are still used in e.g. Jigasi, the project is not actively developed anymore. Improvements, bugfixes and builds are entirely based on community contributions.

Installation

Releases

Windows and macOS

Download the installers from GitHub releases.

Debian/Ubuntu

An APT repository is available at https://nexus.ingo.ch/jitsi-desktop/. Note the trailing slash at the end of the distro-name. This is required since the repository has no components.

deb https://nexus.ingo.ch/jitsi-desktop-unstable/ <distro>/

RPM Distros

Sorry, there are currently no rpm packages available.

Snapshots

Snapshot or pre-release builds are also available in additional repositories.

• Windows and macOS: See https://github.com/jitsi/jitsi/releases
• Debian/Ubuntu: https://nexus.ingo.ch/jitsi-desktop-unstable/

Helpful Resources

• Documentation Wiki
• Community Forums
• The old website

Contributing

Please, read the contribution guidelines before opening a new issue or pull request.

ice4j's Issues

Add support for STUN candidates

Add support for STUN candidates

Original issue reported on code.google.com by [email protected] on 12 Jan 2010 at 2:07

HttpDemuxFilter missing PATCH request method

What steps will reproduce the problem?
1. Send a packet via http containing a 'PATCH' request method (Jitsi Video 
Bridge, JVB, uses this verb for the REST API).  This is used for signaling in 
JVB, here is an example JSON body:  http://pastebin.com/CmLstLcP

2. HttpDemuxFilter will not accept() the packet

What is the expected output? What do you see instead?
'PATCH' method should be accepted as a valid HTTP verb/request method.

What version of the product are you using? On what operating system?
This issue is still present in current ice4j head, r507.

Additional info:
Without this change, Jitsi Video Bridge's rest API does not work to establish 
streaming media, as it relies on PATCH.

Original issue reported on code.google.com by [email protected] on 30 Jun 2015 at 10:36

Deadlock observed in ice4j code

We are observing deadlock using the latest version of ice4j(r300) library. We 
analysed ice4j code and could see a possibility of a deadlock occuring. Let me 
explain the scenario

After run() method of Pacemaker class is called through 
ConnectivityCheckClient.startChecks(CheckList checkList) method, Thread1 inside 
the run() method enters into the wait state due to wait(waitFor). Consider the 
case when stop method of ConnectivityCheckClient.java is called by 
Agent.terminate() method and it sets paceMaker.running as false and before it 
takes lock of paceMaker object, waitFor time elapses, Thread1 reaches the 
finally block and starts waiting for the lock of the linked list paceMakers 
object because of the statement synchronized (paceMakers)

Thread2 which is inside the stop() method of ConnectivityCheckClient.java and 
has taken the lock of the paceMakers object, now tries to take the lock of the 
pacemaker object in the statement  synchronized(paceMaker).

Now this could be a potential deadlock scenario as Thread1 is waiting to take 
the lock on paceMakers object held by Thread2 and Thread2 is waiting to take 
the lock on pacemaker object held by Thread1.

Please help us understand this scenario better. How does the ice4j code make 
sure that deadlock is avoided in this scenario, as we can see a deadlock which 
says 

"DEADLOCK DETECTED:
==================

[deadlocked thread] Timer-11:
----------------------------
Thread 'Timer-11' is waiting to acquire lock 
'org.ice4j.ice.ConnectivityCheckClient$PaceMaker@4e2753eb' that is held by 
thread 'ICE PaceMaker: null'

Stack trace:
------------
    org.ice4j.ice.ConnectivityCheckClient.stop(ConnectivityCheckClient.java:1067)
    org.ice4j.ice.Agent.terminate(Agent.java:1896)
    org.ice4j.ice.Agent.checkListStatesUpdated(Agent.java:1663)
    org.ice4j.ice.ConnectivityCheckClient$2.run(ConnectivityCheckClient.java:445)
    java.util.TimerThread.mainLoop(Timer.java:512)
    java.util.TimerThread.run(Timer.java:462)

[deadlocked thread] ICE PaceMaker: null:
---------------------------------------
Thread 'ICE PaceMaker: null' is waiting to acquire lock 
'java.util.LinkedList@77f69162' that is held by thread 'Timer-11'

Stack trace:
------------
    org.ice4j.ice.ConnectivityCheckClient$PaceMaker.run(ConnectivityCheckClient.java:1040)"




Possible Solution:

We might be able to avoid deadlock here by putting the statement 
paceMaker.running = false; in stop method of ConnectivityCheckClient.java 
inside the synchronised block, something like


                synchronized(paceMaker)
                {
                paceMaker.running = false;
                    paceMaker.notify();
                }

Please let us know your view on this

Original issue reported on code.google.com by [email protected] on 6 Mar 2012 at 5:09

Deadlock observed in ice4j code | UPNPHarvester.java

We are observing deadlock using the latest version of ice4j(r302) library. We 
analysed ice4j code and could see a possibility of a deadlock occuring. Let me 
explain the scenario

When UPNPHarvester class is called, control goes to the constructor. 2 
UPNPThread instances are created and their start method is called, then the 
main thread takes lock on the rootSync object and goes into wait state.

Inside the individual thread, when each of then enters the finally block, they 
increase the finishThreads variable and call rootSync.notify() which wakes up 
the waiting main thread. The intent is that when finishThreads c=becomes 2 and 
both the UPNPThread threads have called notify only then the main thread comes 
out of the while loop and continues.

Now consider the case : main thread takes lock of rootSync object and goes into 
wait state. Out of the 2 UPNPThread threads, first one goes into finally and 
calls rootSync.notify(), main thread wakes up. Both main thread and the other 
UPNPThread thread whose start was called are now competing for lock on 
rootSynch object. If main thread gets the lock it is fine, but if the other 
UPNPThread thread gets the lock, it will call rootSync.notify() and exit. Now 
when main thread gets the lock on rootSync object, it will call wait() and go 
into the wait state indefinitely since noone will notify it.


Please let us know your view on this

Original issue reported on code.google.com by [email protected] on 13 Mar 2012 at 11:58

Using ice4j for TURN only, no ICE

If I receive an SDP offer without any ICE candidates from the caller, I
can't use the ICE Agent to perform connectivity checks but I may
sometimes want to use ice4j to setup a TURN relay. Then I would just
put the TURN server IP into my SDP answer in the "c=" line.

Is this possible with the ice4j API?

Could the Agent.nominate() method be used, or does that require the peer
to be responding to checks?

Could a RelayedCandidate be constructed manually perhaps or should it be
done through the Agent class or some other application-facing API needs to be added for this?

How to add support for TCP to ice4j

Hi

I intend to use add support for TCP for ICE[TURN/STUN] in ice4j. Kindly please 
provide me some souce code or hint to proceed in order to add support of TCp in 
ice4j for TURN and STUN. Kindly please also let me know till when the TCP based 
ice4j support would be released.

Regards
Viks

Original issue reported on code.google.com by [email protected] on 15 Feb 2011 at 7:18

Move project to Github

Github is more popular and contains more productive efficient tools for 
contributing.
Could you export project to github?

Original issue reported on code.google.com by [email protected] on 8 Jan 2015 at 9:48

NPE in MediaDescription#setAttribute() because CandidateAttribute#attribute is null

What steps will reproduce the problem?
- Create Agent and add audio stream, likle in test/ICE.java
- call IceSdpUtils#initSessionDescription()
- get 1st MediaDescription from new SessionDescription
- call MediaDescription.setAttribute("foo", "bar");

    Exception in thread "main" java.lang.NullPointerException
        at gov.nist.javax.sdp.MediaDescriptionImpl.setAttribute(MediaDescriptionImpl.java:505)

What version of the product are you using? On what operating system?
r360

Original issue reported on code.google.com by [email protected] on 5 Nov 2013 at 1:13

LifetimeAttribute decodes incorrect location in message bytes

What steps will reproduce the problem?
1. connection using a turn server relay
2.
3.

What is the expected output? What do you see instead?
expected turn allocation timeout from turn server is suppose to be 600 for 10 
minutes but instead read it as a huge number instead.


What version of the product are you using? On what operating system?
latest


Please provide any additional information below.

method decodeAttributeBody in class LifetimeAttribute is reading the wrong byte 
offset, hard-coded to be from zero.
should be changed to 

lifetime = ((attributeValue[offset] << 24) & 0xff000000) +
            ((attributeValue[offset+1] << 16) & 0x00ff0000) +
            ((attributeValue[offset+2] << 8) & 0x0000ff00) +
            (attributeValue[offset+3] & 0x000000ff);

Original issue reported on code.google.com by [email protected] on 20 May 2014 at 10:31

Attachments:

• LifetimeAttribute.java

Java 1.5 compiler codes

The Java 1.5 compiler don't allow @Override annotation on interface 
implementations.
The joined patch fix the problem.

Original issue reported on code.google.com by [email protected] on 16 Apr 2013 at 3:35

Attachments:

• ice4j-java-1.5.patch

CandidateAttribute.clone() causes NullPointerException

What steps will reproduce the problem?
1. Clone SDP attributes of a message (e.g. create a response to a 407 message 
using JainSip). At some point, this will call clone() on an instance of 
CandidateAttribute.

What is the expected output? What do you see instead?
- return a reference to the attribute; 
- clone() always returns null;

What version of the product are you using? On what operating system?
Release 413; building from Eclipse; the operating system is Windows 8.1


Please provide any additional information below.
Replacing “return null;” with “return this;” solved the issue for us

Original issue reported on code.google.com by [email protected] on 22 Jul 2014 at 1:15

Difficult to set socket timeout for DatagramSockets

If one wants to set a socket timeout to a DatagramSocket received from a CandidatePair, this operation has a good chance of blocking forever, since the Connector class is likely to be blocked within the receive() method on the underlying DatagramSocket. This results in non-deterministic (and most of the time - indefinitely blocking) behavior when calling setSoTimeout().

ICE4j to support NIO sockets

Currently ICE4j only supports plain blocking sockets, please correct me here if I am wrong. I would really love to see NIO support as well. I believe such support will bring certain performance benefits and more importantly would provide flexibility and choice when integrating ICE4j with other frameworks and libraries that are async in nature.

Any thoughts on this?

Many thanks!

Can produce multiple local candidates with the same priority

Ref: https://tools.ietf.org/html/rfc5245#section-4.1.2

Each candidate for a media stream MUST have a unique priority...

The candidates produced for a Jitsi Videobridge include candidates with non-unique priorities, such as:

a=candidate:1 1 UDP 2130706431 172.16.91.23 10025 typ host
a=candidate:2 1 SSLTCP 2130706431 172.16.91.23 443 typ host
a=candidate:3 1 SSLTCP 1677724415 10.62.20.57 443 typ srflx raddr 172.16.91.23 rport 443
a=candidate:4 1 UDP 1677724415 10.62.20.57 10025 typ srflx raddr 172.16.91.23 rport 10025

The prioritisation should be taking the protocol into account, preferring UDP over TCP candidates.

missing class HarvestingTimeStat

What steps will reproduce the problem?
1. No build ( missing class HarvestingTimeStat )
2.
3.

What is the expected output? What do you see instead?
Correct build

What version of the product are you using? On what operating system?


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 8 Oct 2012 at 2:46

Add support for TURN candidates

Add support for TURN candidates

Original issue reported on code.google.com by [email protected] on 12 Jan 2010 at 2:08

Does ice4j support TURN over TLS?

If not, could the MultiplexingTcpHostHarverster (or TCPHostHarvester - see issue #32) be subclassed to do TLS?

I notice it is possible to add a TurnCandidateHarvester with the TLS
Transport, e.g.

  iceAgent.addCandidateHarvester(
     new TurnCandidateHarvester(
        new TransportAddress(server, port, Transport.TLS)
     )
  );

but it doesn't look like ice4j uses these harvesters.

Wrong preference for choosing default candidate (not in accordance with rfc5245)

What steps will reproduce the problem?
Just see sources:
Candidate.java getDefaultPreference() and Component.java 
selectDefaultCandidate()

The issue is wrong preference for choosing default candidate. 

What is the expected output? What do you see instead?
Candidates priority must be:
relayed 
reflexive 
host

Currently designed in ice4j:
relayed
host
reflexive 

https://tools.ietf.org/html/rfc5245#page-25

   It is RECOMMENDED that default candidates be chosen based on the
   likelihood of those candidates to work with the peer that is being
   contacted.  It is RECOMMENDED that the default candidates are the
   relayed candidates (if relayed candidates are available), server
   reflexive candidates (if server reflexive candidates are available),
   and finally host candidates.

What version of the product are you using? On what operating system?
latest trunk version, revision 470

Please provide any additional information below.

Nov 10, 2014 3:32:33 PM org.ice4j.ice.Agent gatherCandidates
INFO: Gather candidates for component command.RTP
Nov 10, 2014 3:32:33 PM org.ice4j.ice.Agent createComponent
INFO:   [fe80:0:0:0:a6:19ff:fe55:827a]:8888/udp (host)
Nov 10, 2014 3:32:33 PM org.ice4j.ice.Agent createComponent
INFO:   10.0.0.83:8888/udp (host)
Nov 10, 2014 3:32:33 PM org.ice4j.ice.Agent createComponent
INFO:   55.171.215.212:8888/udp (srflx)
Nov 10, 2014 3:32:33 PM com.streamer.iceagent.Ice createStream
INFO: RTP Component created in 75 ms
Nov 10, 2014 3:32:33 PM com.streamer.iceagent.Ice createAgent
INFO: Total harvesting time: 123ms.

media stream:command (component count=1)
Component id=1 parent stream=command
3 Local candidates:
default candidate: candidate:2 1 udp 2130706431 10.0.0.83 8888 typ host
candidate:1 1 udp 2130706431 fe80:0:0:0:a6:19ff:fe55:827a 8888 typ host
candidate:2 1 udp 2130706431 10.0.0.83 8888 typ host
candidate:3 1 udp 1677724415 55.171.215.212 8888 typ srflx raddr 10.0.0.83 
rport 8888
no remote candidates.

Original issue reported on code.google.com by [email protected] on 10 Nov 2014 at 4:04

Switch to Apache License

Not an issue, but a request to switch this project to APL instead of LGPL, along the same lines as libjitsi
https://github.com/jitsi/libjitsi/blob/master/LICENSE

Mavenization

Could you make pom.xml and deploy dependency to Maven Central?

Original issue reported on code.google.com by [email protected] on 8 Jan 2015 at 9:43

The library can’t be included in an Android app

What steps will reproduce the problem?
1. Import Ice4j into an Android app
2. Build the app

What is the expected output? What do you see instead?
The app should be built, however it won’t as it imports classes from JainSip, 
whose package names start with javax. This is not allowed and the following 
error message is displayed:

Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.

This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.

Etc.

What version of the product are you using? On what operating system?
Release  413; building from Eclipse; the operating system is Windows 8.1

Please provide any additional information below.
The library can be used after JainSip has been repackaged and the imports in 
ice4j have been modified accordingly, however, our understanding is that due to 
licencing issues the new package names should not contain any references to 
java or javax. Would you consider providing a version (perhaps also covered by 
LGPL) that can be used in an Android application in compliance with the 
licences that currently cover the library and its dependencies?

Original issue reported on code.google.com by [email protected] on 22 Jul 2014 at 1:14

Connectivity check clients

Implement the procedures from Section 7.1 in the ICE spec
(http://tools.ietf.org/html/draft-ietf-mmusic-ice-19#section-7.1)

Original issue reported on code.google.com by [email protected] on 17 Mar 2010 at 1:21

sdess.getAttribute(ICE_PWD/ICE_UFRAG) is null

What steps will reproduce the problem?
1.  IceSdpUtils.parseSDP(localAgent, remoteSDP);
2.  print string sdess.getAttribute(ICE_PWD) or ICE_UFRAG is null
3.

What is the expected output? What do you see instead?

sdess.getAttribute(ICE_PWD/ICE_UFRAG) should not be null.
Then startConnectivityEstablishment() cannot complete.

What version of the product are you using? On what operating system?

SVN 415

Please provide any additional information below.

Part of my remoteSDP is following:

a=ice-ufrag:I9KTEufCqgXQFmE4
a=ice-pwd:Jp4CF6Hx3rCLCxc6LnF4tsiU
a=ice-options:google-ice
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=recvonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000

Original issue reported on code.google.com by [email protected] on 29 Jul 2014 at 12:26

Disables IPv6 harvesters, no reason given

The TURN server has both an A record and an AAAA record for IPv6.

When the DNS lookup returns the AAAA record, ice4j just logs the following:

I/dateHarvesterSetElement(11673): Disabling: TURN harvester(srvr: [2001:67c:1388:1001::6]:3478/udp)

and doesn't try to use the relay at all. The log message comes from the class CandidateHarvesterSetElement, it has been truncated in the log message.

The device where it is running is an Android device and IPv6 is working on the device (it is on a dual IPv4 and IPv6 wifi)

When it disables the candidate in this way, it doesn't make any effort to find the A record and use that instead, so it ends up with no relay at all.

Shared sockets

Add support for shared sockets

Original issue reported on code.google.com by [email protected] on 12 Jan 2010 at 2:08

Add support for UPnP candidates

Add support for UPnP candidates

Original issue reported on code.google.com by [email protected] on 12 Jan 2010 at 2:07

ice4j has a bug in the role conflict processing code

RFC5242, section 5.2 (determining role) describes the tie-breaker value as 
follows:

      To resolve this, each agent MUST select a random number, called
      the tie-breaker, uniformly distributed between 0 and (2**64) - 1
      (that is, a 64-bit positive integer).  This number is used in
      connectivity checks to detect and repair this case, as described
      in Section 7.1.2.2.

The tie-breaker is a 64 bit unsigned number.  Right now, ice4j uses the signed 
'long' type to store this value.  Unfortunately, blind comparisons of 
tie-breaker values cast as 'long' will fail in cases where a large tie breaker 
value with the top bit set to '1' will be interpreted as negative and less than 
a lower value.  

For an example, try comparing 0xffff_ffff_ffff_ffff (or -1)  to 0 using longs.  
For this case, 0xffff_ffff_ffff_ffff should win since it's the greater unsigned 
value, but since it will be cast as '-1', it will lose the comparison.

Since java doesn't support unsigned long types, I added a helper function to 
compare two long values as if they were unsigned long values and will correct 
this bug.

The patch also adds another helper function to set the tieBreaker value in case 
a user of the library needs to override the generated tieBreaker value to force 
ice4j to assume the ICE-CONTROLLING role.

Original issue reported on code.google.com by [email protected] on 14 Apr 2015 at 7:29

Attachments:

• ice4j_role_conflict_bug_and_override_tiebreaker.diff

Add support for Jingle node candidates

Add support for Jingle node candidates

Original issue reported on code.google.com by [email protected] on 12 Jan 2010 at 2:08

ICE4J Thread Stuck issue

Hi,

I am using some ICE4J library for STUN and ICE for some dummy application.

While using is I am facing following error. Would you please help to overcome 
this issue.
Thanks in advance for help.

Regards
KD
//------------------------------------------------------------------
DEADLOCK DETECTED:
==================

[deadlocked thread] Timer-11:
----------------------------
Thread 'Timer-11' is waiting to acquire lock 
'org.ice4j.ice.ConnectivityCheckClient$PaceMaker@4e2753eb' that is held by 
thread 'ICE PaceMaker: null'

Stack trace:
------------
    org.ice4j.ice.ConnectivityCheckClient.stop(ConnectivityCheckClient.java:1067)
    org.ice4j.ice.Agent.terminate(Agent.java:1896)
    org.ice4j.ice.Agent.checkListStatesUpdated(Agent.java:1663)
    org.ice4j.ice.ConnectivityCheckClient$2.run(ConnectivityCheckClient.java:445)
    java.util.TimerThread.mainLoop(Timer.java:512)
    java.util.TimerThread.run(Timer.java:462)

[deadlocked thread] ICE PaceMaker: null:
---------------------------------------
Thread 'ICE PaceMaker: null' is waiting to acquire lock 
'java.util.LinkedList@77f69162' that is held by thread 'Timer-11'

Stack trace:
------------
    org.ice4j.ice.ConnectivityCheckClient$PaceMaker.run(ConnectivityCheckClient.java:1040)

Original issue reported on code.google.com by [email protected] on 1 Mar 2012 at 7:16

• Merged into: #14

Connectivity check servers

Implement the procedures from Section 7.2 in the ICE spec
(http://tools.ietf.org/html/draft-ietf-mmusic-ice-19#section-7.2)

Original issue reported on code.google.com by [email protected] on 17 Mar 2010 at 1:22

Implement support for draft-ietf-mmusic-ice-19

A test issue.

Original issue reported on code.google.com by [email protected] on 12 Jan 2010 at 12:53

Message decode offset error

I found two issues in the project on 2014/11/24. Now one has been fixed, but another was ignored by me.

In this file "\src\main\java\org\ice4j\message\Message.java", the founktion "decode" line 1154 is "offset += (4 - (att.getDataLength() % 4));".
I think it should be like this "offset += (4 - (att.getDataLength() % 4)) % 4;".

Because when the attribute's lenth is 0, the result was 4. but we need the offset += 0.
the ver. is SHA-1: 8b70299 on 2015/12/3

New release?

Any plans on making a new release? Latest available in maven central is 1.0 which is very old - if you're relying on any new features / bugfixes since then (like me), you need to build and upload a version yourself, which is quite cumbersome to say the least...

using multiple Agents binding to specific different local IPs

since the HostCandidateHarvester is statically initialized (allowedInterfaces/allowedAddresses) from the StackProperties, i can't find a way to use multiple Agents binding to specific local IPs only.

Am i missing something? Do i have to implement my own host candidate harvester?

Deadlock in PsuedoTCP

We are occasionally getting stuck in deadlocks when using PsuedoTCP.

We haven't been able to create a an easily reproducible example but we have 
logged the thread-dump from one occasion when it occurs. 

MessageReadThread@6558 daemon, prio=5, in group 'main', status: 'MONITOR'
     blocks PseudoTcpReceiveThread@6559
     blocks pool-40-thread-5@5853
     waiting for PseudoTcpReceiveThread@6559 to release lock on <0x1f78> (a org.ice4j.pseudotcp.PseudoTCPBase)
      at org.ice4j.pseudotcp.PseudoTCPBase.recv(PseudoTCPBase.java:591)
      at org.ice4j.pseudotcp.PseudoTcpSocketImpl$PseudoTcpInputStream.read(PseudoTcpSocketImpl.java:761)
      at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
      at sun.security.ssl.InputRecord.readV3Record(InputRecord.java:554)
      at sun.security.ssl.InputRecord.read(InputRecord.java:509)
      at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
      at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884)
      at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
      at java.io.FilterInputStream.read(FilterInputStream.java:133)
      at com.google.protobuf.AbstractMessageLite$Builder$LimitedInputStream.read(AbstractMessageLite.java:263)
      at com.google.protobuf.CodedInputStream.readRawBytes(CodedInputStream.java:851)
      at com.google.protobuf.CodedInputStream.readBytes(CodedInputStream.java:329)
      at com.degoo.protocol.ClientProtos$NetworkMessage.<init>(ClientProtos.java:8927)
      at com.degoo.protocol.ClientProtos$NetworkMessage.<init>(ClientProtos.java:8866)
      at com.degoo.protocol.ClientProtos$NetworkMessage$1.parsePartialFrom(ClientProtos.java:8960)
      at com.degoo.protocol.ClientProtos$NetworkMessage$1.parsePartialFrom(ClientProtos.java:8955)
      at com.google.protobuf.AbstractParser.parsePartialFrom(AbstractParser.java:200)
      at com.google.protobuf.AbstractParser.parsePartialDelimitedFrom(AbstractParser.java:241)
      at com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:253)
      at com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:259)
      at com.google.protobuf.AbstractParser.parseDelimitedFrom(AbstractParser.java:49)
      at com.degoo.protocol.ClientProtos$NetworkMessage.parseDelimitedFrom(ClientProtos.java:9133)
      at com.degoo.backend.ice4j.NATConnection$MessageReadThread.run(NATConnection.java:365)

PseudoTcpReceiveThread@6559 daemon, prio=5, in group 'main', status: 'MONITOR'
     blocks PseudoTcpClockThread@6560
     blocks MessageReadThread@6558
     waiting for MessageReadThread@6558 to release lock on <0x1f84> (a java.lang.Object)
      at org.ice4j.pseudotcp.PseudoTcpSocketImpl.releaseAllLocks(PseudoTcpSocketImpl.java:493)
      at org.ice4j.pseudotcp.PseudoTcpSocketImpl.onTcpClosed(PseudoTcpSocketImpl.java:484)
      at org.ice4j.pseudotcp.PseudoTCPBase.closedown(PseudoTCPBase.java:1574)
      at org.ice4j.pseudotcp.PseudoTCPBase.process(PseudoTCPBase.java:927)
      at org.ice4j.pseudotcp.PseudoTCPBase.parse(PseudoTCPBase.java:852)
      at org.ice4j.pseudotcp.PseudoTCPBase.notifyPacket(PseudoTCPBase.java:486)
      at org.ice4j.pseudotcp.PseudoTcpSocketImpl.receivePackets(PseudoTcpSocketImpl.java:572)
      at org.ice4j.pseudotcp.PseudoTcpSocketImpl.access$000(PseudoTcpSocketImpl.java:18)
      at org.ice4j.pseudotcp.PseudoTcpSocketImpl$1.run(PseudoTcpSocketImpl.java:401)
      at java.lang.Thread.run(Thread.java:722)


We are using revision #r351 and are running it on Java 7 and Windows 7. I'm 
guessing that there's some place in the code where the synchronization doesn't 
occur in the correct order, thus causing a circular lock dependency that 
creates this deadlock.

Original issue reported on code.google.com by [email protected] on 4 Sep 2013 at 10:00

Implement the connectivity check procedures.

Implement the procedures from sections 
5.7 Forming the Check Lists for an Initial Offer
5.8 Scheduling Checks for an Initial Offer
6.3 Forming the Check List for the Initial Answer
6.4 Performing Ordinary Checks for the Initial Answer

Original issue reported on code.google.com by [email protected] on 17 Mar 2010 at 1:28

Rename MultiplexingTCPHostHarvester

"Multiplexing" doesn't need to be in the name. Just TCPHostHarvester would be simpler and less confusing.

AbstractTcpListener, incorrect length computations

org.ice4j.ice.harvest.AbstractTcpListener.isFirstDatagramPacket(...)
    line 130
    incorrect: if (len >= googleTurnSslTcp.length)
    correct  : if (len - off >= googleTurnSslTcp.length)

    line 158
    incorrect: if (len >= 10 && ...)
    correct  : if (len - off >= 10 && ...)

TURN connection loss after 10 minutes

When establishing the connection between two android phones via relay server (TURN), I observe that the connection is always lost after 10 minutes with SocketTimeoutException.

In know that the default lifetime of the relay connection is 10 minutes according to RFC5766 (https://tools.ietf.org/html/rfc5766 page 8). According to this specification the client sends refresh requests to the TURN server to keep the connection from getting closed.

Can it be that ice4j does not send these refresh messages to the server? Do I have to configure the Agent for that. Or what am I potentially doing wrong?

Deadlock in ice4j code

What steps will reproduce the problem?
1. Revision r283 for ice4j fixes a couple of deadlock problems. But when i 
analyzed the code, i see possibilities of introducing deadlock in the fix.

Precisely speaking, the code of concern lies in ConnectivityCheckClient.java

Inside the run() method for class PaceMaker, there is a finally block which has 
a synchronized(this) statement. Since run() method is already synchronized 
method it has lock on the PaceMaker object, and hencesynchronized(this) 
statement on the same object can result in deadlock.

Please help me understand this better. How is the deadlock situation avoided 
here.

What is the expected output? What do you see instead?
We see deadlock of threads for ConnectivityCheckClient.stop

What version of the product are you using? On what operating system?
We are using r300 but the problem was introduced in r283

Original issue reported on code.google.com by [email protected] on 2 Mar 2012 at 11:04

• Merged into: #14

DATA_INDICATION encode error with STUN(TURN)

What steps will reproduce the problem?
1. receive data from peer.
2. new message, set message type and put Attribute
3. encode.

What is the expected output? What do you see instead?
I wish get a byte array, but an Exception occured.

What version of the product are you using? On what operating system?
I get latest version source code by svn.(2014-11-24)
I run it on Windows8.1

Please provide any additional information below.
I found the method/function "encode()" in 
"org.ice4j.attribute.DataAttribute.java" maybe has a bug:

byte binValue[] = new byte[HEADER_LENGTH + getDataLength() +
                                   (padding ? (getDataLength() % 4) : 0)];

it should be written so:

byte binValue[] = new byte[HEADER_LENGTH + getDataLength() +
                                   (padding ? ((4-(getDataLength() % 4))% 4) : 0)];

Original issue reported on code.google.com by [email protected] on 24 Nov 2014 at 2:26

Send command from webservice trhead socket client to socket server on android device

I have this problem: I have to request a device position through a SOAP webservice to a listening service on Android device through a socket.

On the Android device, there is a socket server service listening. The Android device's IP address for the socket connection is sent previously by a background service to a SOAP webservice listening on a server web. I implemented this scenario and it's working properly with WIFI network, but if I switch to an Internet GSM network, the socket is not open because the addresses of many operators are private and not public.

Is there a way to implement the same scenario?
I read about XMPP, ICE,TURN, etc. but I'm new to these technologies and I do not know if it's the right way.

Nomination highest priority: message and actual nominated pair mismatch

In class DefaultNominator's method strategyNominateHighestPrio, the logger print the 'validPair' but the following line nominate 'pair'. Since the method getValidPair in IceMediaStream return the first valid candidate pair of a component, 'validPair' and 'pair' may differ from each other.
Also, I wonder that is this correct to nominate the first valid pair of a component in strategyNominateHighestPrio?

Re-Connect on Fail

Is there a way to use the agent to re-connect if there is a failed connection, or do I need to re-setup the agent from scratch? Or I can call startConnectivityEstablishment again after a fail?

can't send keepAliveMessage with coturn.

public void run()
{
try
{
do
{
StunCandidateHarvest harvest = this.harvest.get();

                if ((harvest == null)
                        || !harvest.runInSendKeepAliveMessageThread())
                {
                    break;
                }
            }
            while (true);
        }
        finally
        {
            StunCandidateHarvest harvest = this.harvest.get();

            if (harvest != null)
                harvest.exitSendKeepAliveMessageThread();
        }
    }

private boolean runInSendKeepAliveMessageThread()
{
synchronized (sendKeepAliveMessageSyncRoot)
{
// Since we're going to #wait, make sure we're not canceled yet.
if (sendKeepAliveMessageThread != Thread.currentThread())
return false;
if (sendKeepAliveMessageInterval
== SEND_KEEP_ALIVE_MESSAGE_INTERVAL_NOT_SPECIFIED)
{
return false;
}

        // Determine the amount of milliseconds that we'll have to #wait.
        long timeout;

        if (sendKeepAliveMessageTime == -1)
        {
            /*
             * If we're just starting, don't just go and send a new STUN
             * keep-alive message but rather wait for the whole interval.
             */
            timeout = sendKeepAliveMessageInterval;
        }
        else
        {
            timeout
                = sendKeepAliveMessageTime
                    + sendKeepAliveMessageInterval
                    - System.currentTimeMillis();
        }
        // At long last, #wait if necessary.
        if (timeout > 0)
        {
            try
            {
                sendKeepAliveMessageSyncRoot.wait(timeout);
            }
            catch (InterruptedException iex)
            {
            }
            /*
             * Apart from being the time to send the STUN keep-alive
             * message, it could be that we've experienced a spurious
             * wake-up or that we've been canceled.
             */
            return true;
        }
    }

    sendKeepAliveMessageTime = System.currentTimeMillis();
    try
    {
        sendKeepAliveMessage();
    }
    catch (StunException sex)
    {
        logger.log(
                Level.INFO,
                "Failed to send STUN keep-alive message.",
                sex);
    }
    return true;
}

i use coturn test the turnserver. found the channel will be closed after 10 mins. i capture package found .the ice never send keepalive message. after 10 mins, turnserver will close this channel. so i track the code found it's a bug?

first time , the sendKeepAliveMessageTime value is -1, then timeout value is sendKeepAliveMessageInterval, the sendKeepAliveMessageInterval is response from turnserver 60000 second. this thread will be wait the timeout. (the wait function is instable). then the code will be return true and try second time. but the turnserver close the channel After the timeout.

Add support for Host candidates

Add support for local candidates

Original issue reported on code.google.com by [email protected] on 12 Jan 2010 at 2:06

ChannelDataMessageEvent never created?

I'm creating a StunStack and passing a ChannelDataEventHandler, but it never gets called.
Then I looked through your code and saw, that this event is never created, nor the handler is called anywhere. Wat?

AbstractUdpListener, incorrect length computation

org.ice4j.ice.harvest.AbstractUdpListener.getUfrag(...)
    line 166
    incorrect: if (buf == null || buf.length < off + len || len < 20)
    correct  : if (buf == null || buf.length < len || len - off < 20)

Please consider tagging formal release

Formal releases are helpful for downstream package maintainers. Thanks.

Discovery of TURN servers - RFC 5928 support

I notice Jitsi has on option to discover TURN servers.

Does it implement all of RFC 5928, discovery of TURN servers using NAPTR and SRV lookups and possibly trying default A/AAAA records and port numbers?

It would be useful to have the functionality in the ice4j library