https://sourceforge.net/p/peers/bugs/2012-01-22T17:53:51ZRecent changes to bugs2012-01-22T17:53:51Z2012-01-22T17:53:51Zyohannmartineauhttps://sourceforge.net/u/yohannmartineau/https://sourceforge.net35e2f212f5ab759fd20be1c6645d35945a945770

In peers.xml, if network interface ip address is not filled, peers chooses the first interface with a local network area address in all network interfaces provided by java API \(method isSiteLocalAddress\). If there are several network interfaces on the same host connected to the same or different local area network\(s\), peers may choose a wrong interface to send messages. To avoid this issue, one possibility is to send REGISTER request on all interfaces and select the interface which receives the first response.

2011-12-29T15:06:54Z2011-12-29T15:06:54Zrbesenhttps://sourceforge.net/u/rbesen/https://sourceforge.net3819b0e192b2fcbe32c92382087f9cdd7d4275d0

The call is chopping, sometimes the problem is in the middle of the call, other at the beginning and others not. The problem happen because the rtp packed flow get low, Above you can see a TCPDump: 20:39:54.365614 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.365779 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:54.386614 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.386854 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:54.407613 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.407779 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:54.428612 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.428778 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:54.449620 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.449791 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:54.470612 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.470780 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:54.491614 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.491780 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:54.512613 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.512782 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:54.533611 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.533716 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:54.554609 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.554744 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:54.575621 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.575758 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:54.596616 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.596787 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:54.617614 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:54.617799 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:57.925171 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:57.969160 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:57.969168 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:57.993722 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:57.993758 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:57.993802 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:57.993830 IP 172.16.16.220.8000 > 172.16.16.201.11950: UDP, length 172 20:39:57.993930 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.037158 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.037177 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.081188 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.081199 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.081202 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.125175 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.125186 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.169164 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.169174 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.213163 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.213171 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.257166 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.257175 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.301175 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.301182 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.301185 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.345166 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 20:39:58.345174 IP 172.16.16.201.11950 > 172.16.16.220.8000: UDP, length 172 Looks like something wrong when peers try to capture de audio from microphone, debbuging the RTPSender is possible watch this part of code is taking so much time: try \{ while \(\!isStopped && numBytesRead < buf\_size\) \{ // expect that the buffer is full tempBytesRead = encodedData.read\(buffer, numBytesRead, buf\_size - numBytesRead\); numBytesRead += tempBytesRead; \} \} catch \(IOException e\) \{ Logger.getLogger\(RtpSender.class\).error\("input/output error", e\); return; \}

2011-09-23T07:44:23Z2011-09-23T07:44:23ZAnonymoushttps://sourceforge.net/u/userid-None/https://sourceforge.netb5829db2a97cc99417ae6cb9ec8b205421113b1c

When I make two call by peers\(0.4.3\), the voice will be lag and intermittent. The peers.log got some error message. When make only one call, everything is fine. How can I config peers to fix the problem? Or may I have some hints to change the source code? Thanks.

2011-08-16T10:39:00Z2011-08-16T10:39:00Zmainiakhttps://sourceforge.net/u/mainiak/https://sourceforge.net7a260d6e933a9c30ec302a4a9ca8ac140f94f153

When I called a party, which was not picking up, I hangup the call. Gui shows no phone call but phone on the desk is still ringing.

2011-06-23T22:06:14Z2011-06-23T22:06:14Zyohannmartineauhttps://sourceforge.net/u/yohannmartineau/https://sourceforge.net38024daf62e491e29bf528c9219deb293c7f3f37

Environment: Asterisk 1.8.4.2 Caller: peers-0.4.1 Callee: any softphone, test performed with peers-0.4.1 Peers calls any softphone, peers hangup, but Asterisk answers with 481 call leg/transaction does not exist. If the same test is performed with Ekiga, Asterisk answers with 200 OK.

2011-06-21T17:27:00Z2011-06-21T17:27:00Zyohannmartineauhttps://sourceforge.net/u/yohannmartineau/https://sourceforge.netd864f06780f0d7094560aa7fb516a8eddf1d64a6

Thus, with Asterisk 1.8.4.2 ACK is not considered by Asterisk and Asterisk is hanging up after INVITE transaction timeout, i.e. 32s.

2011-05-05T16:26:14Z2011-05-05T16:26:14Zyohannmartineauhttps://sourceforge.net/u/yohannmartineau/https://sourceforge.netcaec1e50d49db037a7ba8ab9a39e60abc47a208b

if a 180 with Content-Type application/sdp is sent to peers, but no content is provided, while clicking hangup on peers, no BYE is sent. see attached sipp script. if Content-Type is removed, BYE is sent while clicking hangup.

2011-04-12T08:58:02Z2011-04-12T08:58:02ZAnonymoushttps://sourceforge.net/u/userid-None/https://sourceforge.net4d7630eae3198610dd5016bd16859d1b9ee0bb21

The following occurs at my side: I start your softphone, enter the number to dial and the callee answers. Everything ok until now. Then, I hang up on the softphone. CallFrame gets closed \(connection closed?\) but on the callee's side, the connection is still open. transport.log shows the BYE command from my side and the response "SIP/2.0 407 Proxy Authentication Required". But there it ends. Shouldn't it resend the BYE with Proxy-Auth as it is sending with INVITE for example? If callee hangs up after caller, it's BYE messages are sent to the caller and therefore the connection is closed. \--> SIP Proxy is challenging on BYE requests Proxy is Server: Avaya SIP Enablement Services User-Agent: Avaya CM/R015x.02.1.016.4 Best, Yvonne

2010-12-01T16:56:56Z2010-12-01T16:56:56Zyohannmartineauhttps://sourceforge.net/u/yohannmartineau/https://sourceforge.net34fe91322343c06fbd35aff7f0b082fb6a74650e

radom crashes on mac os x on hangup, last line in logs shows closeLines, which corresponds to javasound line closing, so the problem is probably within jvm javasound on mac os x \(no stack trace in log file\).

2010-11-23T19:10:17Z2010-11-23T19:10:17Zyohannmartineauhttps://sourceforge.net/u/yohannmartineau/https://sourceforge.netf72a9d175fe3a14fd2e0879df9d70bc87e110924

sometimes, when you configure your account registration state is not displayed in account frame, it's visible in main frame, but not in account frame.