mailmindlin / ice4j Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/ice4j
Automatically exported from code.google.com/p/ice4j
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
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
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:
Add support for STUN candidates
Original issue reported on code.google.com by [email protected]
on 12 Jan 2010 at 2:07
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
Add support for TURN candidates
Original issue reported on code.google.com by [email protected]
on 12 Jan 2010 at 2:08
Add support for UPnP candidates
Original issue reported on code.google.com by [email protected]
on 12 Jan 2010 at 2:07
Add support for local candidates
Original issue reported on code.google.com by [email protected]
on 12 Jan 2010 at 2:06
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:
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
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
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
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
A test issue.
Original issue reported on code.google.com by [email protected]
on 12 Jan 2010 at 12:53
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
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
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
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
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
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
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:
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
Add support for Jingle node candidates
Original issue reported on code.google.com by [email protected]
on 12 Jan 2010 at 2:08
Add support for shared sockets
Original issue reported on code.google.com by [email protected]
on 12 Jan 2010 at 2:08
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
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
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.