https://sourceforge.net/p/peers/patches/2011-06-25T00:45:38ZRecent changes to patches2011-06-25T00:45:38Z2011-06-25T00:45:38Zanirudh rhttps://sourceforge.net/u/anirudhrx/https://sourceforge.netb1130e98a73ad690882da86635af47bdf0e70324

Just figured out the patch system\! Please review and apply. If the patch applied is incomplete, please use http://www.mediafire.com/?3z8enp6uxu68un8

2011-02-12T12:34:26Z2011-02-12T12:34:26Zyohannmartineauhttps://sourceforge.net/u/yohannmartineau/https://sourceforge.net09cfadd164780f0ab8d8be3cf10496309ec24526

some asterisk instances seem to consider user-agents offline if they don't answer notify requests. To bypass this issue, a patch has been developped by cristian david cepeda piscal. This patch adds a NotifyHandler that simply answer 200 OK to notify requests. After this modification, asterisk apparently considers peers online and can route calls towards peers.

2011-01-11T13:39:52Z2011-01-11T13:39:52Zuiltjehttps://sourceforge.net/u/tuijldert/https://sourceforge.netc48f5f18f56fcb84c45a70d6719bfe3cafb0360d

Within the InviteHandler.handleInitialInvite\(\), order of execution is: 1\. send 180 Ringing 2\. tell SipListener about incoming call 3\. update dialog state/handling. 3\. should be done before 2. because the dialog has the wrong state when calling the SipListener. If the SipListener decides to immediately accept the call, a 200 Ok will be sent, the dialog will be set from init to confirmed, followed by an attempt to set it from confirmed to early, leading to an IllegalStateException. Attached patch reverses the order. Please review and apply. Hope this helps, Tom.

2010-12-15T11:08:54Z2010-12-15T11:08:54Zuiltjehttps://sourceforge.net/u/tuijldert/https://sourceforge.net4835a725b1bb0e7f49159a0aa69cf6136753628b

Multiple SIP responses can be executed in parallel within 1 ClientTransaction \(probably interfering with transaction state handling as well\). This can lead to 200 OK responses overtaking 180 Ringing responses. Attached patch serializes this by synchronizing the "receivedResponse\(\)" method. Hope this helps, Tom.

2010-10-29T13:43:50Z2010-10-29T13:43:50Zyohannmartineauhttps://sourceforge.net/u/yohannmartineau/https://sourceforge.net68698f5cc985311c1b1f3c6e826f2004da957c48

Some buggy registrars seem to refuse REGISTER with a cseq of 0. This value is valid in RFC3261, but most sip softphones use 1 as their first cseq value. So it makes sense to use 1 as the first cseq value in peers. To use 1 as the first cseq value in peers, modify net.sourceforge.peers.sip.core.useragent.UserAgent.UserAgent. In constructor, use cseqCounter = 1;

2010-10-22T15:55:20Z2010-10-22T15:55:20Zuiltjehttps://sourceforge.net/u/tuijldert/https://sourceforge.net287600126d8521f6494a2654399fc9e4247574ce

On receiving provisional responses \(1xx\) within a non-INVITE client transaction, it is logical to reset the re-transmission timer, as the server side has indicated that it is working on it. This is currently not happening. The timer is not reset and a retransmission is done when timer E fires regardless. Attached patch will reset the timer on receiving a provisional response. Hope this helps, Tom.

2010-10-22T15:47:12Z2010-10-22T15:47:12Zuiltjehttps://sourceforge.net/u/tuijldert/https://sourceforge.netf90de7b04453052211f51a8abceb88a73402b9e3

When an rtp-stream is stopped, any packets, waiting to be sent, are still sent. This patch prevents that. Hope this helps, Tom.

2010-10-21T15:05:06Z2010-10-21T15:05:06Zuiltjehttps://sourceforge.net/u/tuijldert/https://sourceforge.net1d37fd7c35516744cb25a4489179d5eea133c53d

When refreshing \(dropping and creating\) rtp-streams, time to wait for closure should depend on RtpSession.TIMER. Attached patch does just that. Hope this helps, Tom.

2010-10-21T09:48:52Z2010-10-21T09:48:52Zuiltjehttps://sourceforge.net/u/tuijldert/https://sourceforge.net7776b6168a8c5fda7a75d5d2bcd5bac1aeaf0ede

Creation of MainFrame.mainPanel is not needed. The JFrame.getContentPane\(\) will get you the Container needed. Attached patch gets rid of the JPanel creation. Hope this helps, Tom.

2010-10-15T13:09:52Z2010-10-15T13:09:52Zuiltjehttps://sourceforge.net/u/tuijldert/https://sourceforge.net9617b2589daa7bebec98548fe3ebe44e7b1ee0fa

Attached, a patch that enhances the handling of registrations, including: \- introduction of "Expires" header \(including default\). \- addition of unregister all \(wildcard\) \- improved separation of functionality - RegisterHandler handles REGISTERs under control of InitialRequestManager Hope this helps, Tom.