livem / jain-sip Goto Github PK

See http://telestax.zendesk.com/tickets/30867

What steps will reproduce the problem?
1.Send an INVITE and CANCEL it

What is the expected output? What do you see instead?
I would expect the listener to be called, instead an exception is logged in the 
console 

What version of the product are you using? On what operating system?
latest svn on google canary.

Please provide any additional information below.
Copy&paste from the console:

SIP message received: INVITE sip:[email protected]:52849;transport=ws SIP/2.0
Call-ID: [email protected]
CSeq: 1 INVITE
From: 
<sip:[email protected]>;tag=29333067_3d5109ff_77d485e5-956c-4261-a33c-f43b0491
91b7
To: <sip:[email protected]>
Max-Forwards: 70
Contact: <sip:[email protected]:5082;transport=ws>
Content-Type: application/sdp
Via: SIP/2.0/WS 
208.38.164.6:5082;branch=z9hG4bK77d485e5-956c-4261-a33c-f43b049191b7_3d5109ff_25
28434330093335;rport
Content-Length: 4069

v=0
o=- 2183589562 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS Bb4VdVsIPwBJuXU7ibJqqAw82qhyIc7K9VNu
m=audio 61818 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126
c=IN IP4 95.122.229.88
a=rtcp:61818 IN IP4 95.122.229.88
a=candidate:4242042849 1 udp 2113937151 192.168.153.1 61817 typ host generation 
0
a=candidate:4242042849 2 udp 2113937151 192.168.153.1 61817 typ host generation 
0
a=candidate:2896278100 1 udp 2113937151 192.168.1.36 61818 typ host generation 0
a=candidate:2896278100 2 udp 2113937151 192.168.1.36 61818 typ host generation 0
a=candidate:3471623853 1 udp 2113937151 192.168.64.1 61819 typ host generation 0
a=candidate:3471623853 2 udp 2113937151 192.168.64.1 61819 typ host generation 0
a=candidate:1521601408 1 udp 1845501695 95.122.229.88 61818 typ srflx raddr 
192.168.1.36 rport 61818 generation 0
a=candidate:1521601408 2 udp 1845501695 95.122.229.88 61818 typ srflx raddr 
192.168.1.36 rport 61818 generation 0
a=candidate:2992345873 1 tcp 1509957375 192.168.153.1 52851 typ host generation 
0
a=candidate:2992345873 2 tcp 1509957375 192.168.153.1 52851 typ host generation 
0
a=candidate:3793899172 1 tcp 1509957375 192.168.1.36 52852 typ host generation 0
a=candidate:3793899172 2 tcp 1509957375 192.168.1.36 52852 typ host generation 0
a=candidate:2154773085 1 tcp 1509957375 192.168.64.1 52853 typ host generation 0
a=candidate:2154773085 2 tcp 1509957375 192.168.64.1 52853 typ host generation 0
a=ice-ufrag:C7ACspHwhBfyKBoB
a=ice-pwd:bCJoQbbVEFcMrzx/jYa62xAE
a=ice-options:google-ice
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 
inline:0dGhFqEzuixLqECHfTr8VlAWcnw3aA9KjoI/BgFa
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=ssrc:74897746 cname:f5ybpB+qZQ/fsR8K
a=ssrc:74897746 msid:Bb4VdVsIPwBJuXU7ibJqqAw82qhyIc7K9VNu 
Bb4VdVsIPwBJuXU7ibJqqAw82qhyIc7K9VNua0
a=ssrc:74897746 mslabel:Bb4VdVsIPwBJuXU7ibJqqAw82qhyIc7K9VNu
a=ssrc:74897746 label:Bb4VdVsIPwBJuXU7ibJqqAw82qhyIc7K9VNua0
m=video 61818 RTP/SAVPF 100 116 117
c=IN IP4 95.122.229.88
a=rtcp:61818 IN IP4 95.122.229.88
a=candidate:4242042849 1 udp 2113937151 192.168.153.1 61817 typ host generation 
0
a=candidate:4242042849 2 udp 2113937151 192.168.153.1 61817 typ host generation 
0
a=candidate:2896278100 1 udp 2113937151 192.168.1.36 61818 typ host generation 0
a=candidate:2896278100 2 udp 2113937151 192.168.1.36 61818 typ host generation 0
a=candidate:3471623853 1 udp 2113937151 192.168.64.1 61819 typ host generation 0
a=candidate:3471623853 2 udp 2113937151 192.168.64.1 61819 typ host generation 0
a=candidate:1521601408 1 udp 1845501695 95.122.229.88 61818 typ srflx raddr 
192.168.1.36 rport 61818 generation 0
a=candidate:1521601408 2 udp 1845501695 95.122.229.88 61818 typ srflx raddr 
192.168.1.36 rport 61818 generation 0
a=candidate:2992345873 1 tcp 1509957375 192.168.153.1 52851 typ host generation 
0
a=candidate:2992345873 2 tcp 1509957375 192.168.153.1 52851 typ host generation 
0
a=candidate:3793899172 1 tcp 1509957375 192.168.1.36 52852 typ host generation 0
a=candidate:3793899172 2 tcp 1509957375 192.168.1.36 52852 typ host generation 0
a=candidate:2154773085 1 tcp 1509957375 192.168.64.1 52853 typ host generation 0
a=candidate:2154773085 2 tcp 1509957375 192.168.64.1 52853 typ host generation 0
a=ice-ufrag:C7ACspHwhBfyKBoB
a=ice-pwd:bCJoQbbVEFcMrzx/jYa62xAE
a=ice-options:google-ice
a=sendrecv
a=mid:video
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 
inline:0dGhFqEzuixLqECHfTr8VlAWcnw3aA9KjoI/BgFa
a=rtpmap:100 VP8/90000
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:1978828575 cname:f5ybpB+qZQ/fsR8K
a=ssrc:1978828575 msid:Bb4VdVsIPwBJuXU7ibJqqAw82qhyIc7K9VNu 
Bb4VdVsIPwBJuXU7ibJqqAw82qhyIc7K9VNuv0
a=ssrc:1978828575 mslabel:Bb4VdVsIPwBJuXU7ibJqqAw82qhyIc7K9VNu
a=ssrc:1978828575 label:Bb4VdVsIPwBJuXU7ibJqqAw82qhyIc7K9VNuv0
 jain-sip.js:15420
WebRTCPhoneUA:processRequest() WebRTCPhoneUA.js:409
WebRTCPhoneUA:handleStateMachineInvitedRequestEvent(): 
this.invitedState=INVITED_INITIAL_STATE WebRTCPhoneUA.js:1142
SIP message sent: SIP/2.0 180 Ringing
Call-ID: [email protected]
CSeq: 1 INVITE
From: 
<sip:[email protected]>;tag=29333067_3d5109ff_77d485e5-956c-4261-a33c-f43b0491
91b7
To: <sip:[email protected]>;tag=1359036147432
Max-Forwards: 70
Via: SIP/2.0/WS 
208.38.164.6:5082;branch=z9hG4bK77d485e5-956c-4261-a33c-f43b049191b7_3d5109ff_25
28434330093335;rport
Contact: <sip:[email protected];transport=ws>
User-Agent: WebRTCPhoneUA
Content-Length: 0

 jain-sip.js:20684
WebRTCPhoneUA:handleStateMachineInvitedRequestEvent(): sipUri.getUser()=webrtc 
WebRTCPhoneUA.js:1162
SIP message received: CANCEL sip:[email protected]:52849;transport=ws SIP/2.0
Call-ID: [email protected]
To: <sip:[email protected]>
CSeq: 1 CANCEL
From: 
<sip:[email protected]>;tag=29333067_3d5109ff_77d485e5-956c-4261-a33c-f43b0491
91b7
Via: SIP/2.0/WS 
208.38.164.6:5082;branch=z9hG4bK77d485e5-956c-4261-a33c-f43b049191b7_3d5109ff_25
28434330093335;rport
Max-Forwards: 70
Content-Length: 0

 jain-sip.js:15420
SipProviderImpl:sendResponse(): transaction exists -- cannot send response 
statelessly jain-sip.js:26661
SipProviderImpl.sendResponse jain-sip.js:26661
DialogFilter.processRequest jain-sip.js:25888
SIPServerTransaction.processRequest jain-sip.js:24126
WSMsgParser.processMessage jain-sip.js:15437
WSMsgParser.parsermessage jain-sip.js:15421
websocket.onmessage jain-sip.js:20645
Uncaught SipProviderImpl:sendResponse(): transaction exists -- cannot send 
response statelessly jain-sip.js:26662
SipProviderImpl.sendResponse jain-sip.js:26662
DialogFilter.processRequest jain-sip.js:25888
SIPServerTransaction.processRequest jain-sip.js:24126
WSMsgParser.processMessage jain-sip.js:15437
WSMsgParser.parsermessage jain-sip.js:15421
websocket.onmessage

http://java.net/jira/browse/JSIP-438 and 
https://telestax.zendesk.com/tickets/30955

Exception being thrown

gov.nist.javax.sip.stack.NioTcpMessageProcessor ERROR: Problem processing 
selection key event
java.io.IOException: An existing connection was forcibly closed by the remote 
host
    at sun.nio.ch.SocketDispatcher.write0(Native Method)
    at sun.nio.ch.SocketDispatcher.write(Unknown Source)
    at sun.nio.ch.IOUtil.writeFromNativeBuffer(Unknown Source)
    at sun.nio.ch.IOUtil.write(Unknown Source)
    at sun.nio.ch.SocketChannelImpl.write(Unknown Source)
    at gov.nist.javax.sip.stack.NioTcpMessageProcessor$ProcessorTask.write(NioTcpMessageProcessor.java:135)
    at gov.nist.javax.sip.stack.NioTcpMessageProcessor$ProcessorTask.run(NioTcpMessageProcessor.java:293)
    at java.lang.Thread.run(Unknown Source)

equal() doesn't work on Host and HostPort object

What steps will reproduce the problem?
1. client sends an INVITE
2. server sends a 100 trying
3. server never sends an INVITE response
4. client never times out the INVITE

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


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


Please provide any additional information below.

SIPClientTransactionImpl.inviteClientTransaction() line 841 should be removed:

      } else if (statusCode / 100 == 1) {
        disableRetransmissionTimer();
//        disableTimeoutTimer();
        this.setState(TransactionState._PROCEEDING);

        if (respondTo != null)
          respondTo.processResponse(transactionResponse, encapsulatedChannel, dialog);
        else {
          this.semRelease();
        }

      }

replace while(true) by while(this.lexer.hasMoreChars()

What steps will reproduce the problem?
1. I have tried to add a cancel to the default mobicents example by using the 
following code:
var jainSipCancelRequest=this.jainSipInvitingTransaction.createCancel();
            jainSipCancelRequest.addHeader(this.jainSipContactHeader);
            jainSipCancelRequest.addHeader(this.jainSipUserAgentHeader);
        var jainSipClientTransaction = this.sipProvider.getNewClientTransaction(jainSipCancelRequest);
            jainSipCancelRequest.setTransaction(jainSipClientTransaction);
jainSipClientTransaction.sendRequest();            


What is the expected output? What do you see instead?
Exception is raised complaining about "could not find original tx to cancel. 
RFC 3261 9.1"

But if I change last line to:
jainSipClientTransaction.sendMessage(jainSipCancelRequest);

Everything works.

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

Please provide any additional information below.

Implemenetation of the Java gov.nist.sdp in JavaScript.
Required by some SDP maninuplation in WebRTC client (add bandwidth attribute by 
exemple) in interconnection with legacy SIP End-point (MCU, RCSe) which are not 
accessible via WebRTC native API. 

See http://code.google.com/p/sipservlets/issues/detail?id=119

What steps will reproduce the problem?
1. make a call and enableRetransmissionAlerts for INVITE
2. on ACK disableRetransmissionAlerts (don't think this is really necessary as 
I think the JAIN SIP Stack does this itself)
3. terminate the call

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

The SIPServerTransaction should be cleaned up after all timers have expired, 
however, a reference remains in sipStack.retransmissionAlertTransactions

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

latest snapshot (1.2.2169)

Please provide any additional information below.

Problem is that the constructor of RetransmissionAlertTimerTask never assigns 
the dialogId:

        public RetransmissionAlertTimerTask(String dialogId) {

            this.ticks = SIPTransaction.T1;
            this.ticksLeft = this.ticks;
        }

RetransmissionAlertTimerTask.dialogId is never assigned anywhere.  When alerts 
are disabled the check for dialogId is false and the transaction never gets 
cleaned up:


    public void disableRetransmissionAlerts() {
        if (this.retransmissionAlertTimerTask != null && this.retransmissionAlertEnabled) {
               sipStack.getTimer().cancel(retransmissionAlertTimerTask);
            this.retransmissionAlertEnabled = false;

            String dialogId = this.retransmissionAlertTimerTask.dialogId;
            if (dialogId != null) {
                sipStack.retransmissionAlertTransactions.remove(dialogId);
            }
            this.retransmissionAlertTimerTask = null;
        }
    }

I have attached a file with the fixed constructor.

regards, Mitchell Ackerman ([email protected])

Missing call to RTCPeerConnection.setRemoteDescription()

Those properties don't belong in HA stack but in Ext stack 

org.mobicents.ext.java.sip.TRANSACTION_FACTORY
org.mobicents.ext.java.sip.SIP_PROVIDER_FACTORY
org.mobicents.ext.java.sip.SEND_TRYING_RIGHT_AWAY

See http://java.net/jira/browse/JSIP-432 and 
http://code.google.com/p/sipservlets/issues/detail?id=104

String object has no method equals

Application sending a MESSAGE to itself and getting the response before the 
transaction timer had time to fire
See Exception below

Jul 30 21:34:54,741 [Self Recovery Thread] 
com.avistar.selfrecovery.SelfRecoveryThread ERROR: Error in SelfRecoveryThread:
java.lang.IllegalStateException: Error sending request MESSAGE 
sip:192.168.253.206:5062;transport=TLS SIP/2.0
Call-ID: [email protected]
CSeq: 1 MESSAGE
From: 
<sip:selfrecovery@avistar>;tag=32187016_8a1e29b3_bbfa7541-11b0-4a81-aa80-60d99a8
7c8f6
To: <sip:192.168.253.206:5062>
Max-Forwards: 70
Content-Type: application/vnd.avistar.com+xml
Via: SIP/2.0/TLS 
192.168.253.206:5062;branch=z9hG4bKbbfa7541-11b0-4a81-aa80-60d99a87c8f6_8a1e29b3
_347707431750404
Content-Length: 61

<SelfRecovery>Self recovery keep-alive message</SelfRecovery>
at 
org.mobicents.servlet.sip.message.SipServletRequestImpl.send(SipServletRequestIm
pl.java:1317)
at 
org.mobicents.servlet.sip.message.SipServletRequestImpl.send(SipServletRequestIm
pl.java:994)
at 
com.avistar.selfrecovery.SelfRecoveryThread.sendSelfRecoveryMessageRequest(SelfR
ecoveryThread.java:138)
at com.avistar.selfrecovery.SelfRecoveryThread.run(SelfRecoveryThread.java:42)
Caused by: java.lang.NullPointerException
at 
gov.nist.javax.sip.stack.SIPClientTransaction.startTransactionTimer(SIPClientTra
nsaction.java:1402)
at gov.nist.javax.sip.stack.SIPTransaction.sendMessage(SIPTransaction.java:920)
at 
gov.nist.javax.sip.stack.SIPClientTransaction.sendMessage(SIPClientTransaction.j
ava:489)
at 
gov.nist.javax.sip.stack.SIPClientTransaction.sendRequest(SIPClientTransaction.j
ava:1057)
at 
org.mobicents.servlet.sip.message.SipServletRequestImpl.send(SipServletRequestIm
pl.java:1279)
... 3 more

Use request URI to build the uri parameter of the Authorization header in 
HeaderFactoryImpl.prototype.createAuthorizationHeaderargu2 
=function(response,request,sipPassword,sipLogin)

The current jain sip ha enforces loading jboss cache classes to use the sip lb

Remove debug code in built library jain-sip.js and jain-sip.min.js:
if(logger!=undefined) logger.debug(....) because the logging flow in the 
console is too heavy and overload the console
But keep the debug line in the original JS source code for debug purposes.

Error in parsing Record-Route header
StringMsgParser:processHeader(): catched exception:TypeError: Object 
   record-route has no method 'concatenate' jain-sip.js:12169<http://bart:8080/websockets/jain-sip/js/jain-sip.js>

WebkitPeerConnection00 constructor replace by  webkitRTCPeerConnection
See mail above from serge lachapelle

posted Oct 16, 2012 11:50 AM by Serge Lachapelle

Hi,
We are getting closer to having WebRTC reach stable. As I mentioned a while 
back, we are trying to make the last big changes before  this happens.

As such, we are now hiding the PeerConnection00 class behind a flag 
(--enable-deprecated-peer-connection) both for Canary and M23 beta.

This won't be visible in the chrome://flags page and therefore can't be made to 
stick; you have to launch chrome/chromium with the flag every time if you 
require the old API.
This is a hassle and having you switch APIs is no fun. Rest assured that 
changes going forward will be smaller and smaller... and thanks for all the 
amazing feedback so far!

/Serge

Sometimes NIO Stack gives on 32bit Java 6 under Windows, with Xmx set to 1224M. 

java.lang.OutOfMemoryError 
at sun.misc.Unsafe.allocateMemory(Native Method) 
at java.nio.DirectByteBuffer.<init>(Unknown Source) 
at java.nio.ByteBuffer.allocateDirect(Unknown Source) 
at 
gov.nist.javax.sip.stack.SSLStateMachine.startBuffer(SSLStateMachine.java:181) 
at gov.nist.javax.sip.stack.SSLStateMachine.unwrap(SSLStateMachine.java:238) 
at gov.nist.javax.sip.stack.SSLStateMachine.unwrap(SSLStateMachine.java:174) 
at 
gov.nist.javax.sip.stack.NioTlsMessageChannel.addBytes(NioTlsMessageChannel.java
:165) 
at 
gov.nist.javax.sip.stack.NioTcpMessageChannel.readChannel(NioTcpMessageChannel.j
ava:105) 
at 
gov.nist.javax.sip.stack.NioTcpMessageProcessor$ProcessorTask.read(NioTcpMessage
Processor.java:120) 
at 
gov.nist.javax.sip.stack.NioTcpMessageProcessor$ProcessorTask.run(NioTcpMessageP
rocessor.java:287) 
at java.lang.Thread.run(Unknown Source)


http://stackoverflow.com/questions/3773775/default-for-xxmaxdirectmemorysize . 
It seems that default max . direct. memory size is set to 64M.
While it isn't clear that there is a real problem in JSIP stack, here is few 
reference articles : 
http://stackoverflow.com/questions/6527131/java-using-more-memory-than-the-alloc
ated-memory 
http://www.kdgregory.com/index.php?page=java.byteBuffer 
http://jira.codehaus.org/browse/JETTY-1245

They mainly say that direct byte buffers are resided outside of heap memory, so 
java process could eat much memory than defined by Mx argument.

Ability to configure what kind of buffers will be used by JSIP - direct or 
not-direct ones.

RTCPeerConnection state event callback try to access a null peerconnection 
member of the application

No token for Accept-Contact header name in SIP parser

1. a user can't register with reSIProcate with patch for SIP Over WebSockets 
from SIPML5 because reSIProcate sends back the response to the REGISTER via TCP 
port 5060. I believe it does that because it does not know the port it should 
use.

using rport= in the Via fixes it (even though reSIProcate shouldn't care 
because it is ovr TCP and should reuse the Connection)

2. After the rport fix, the client crashes with the errors below.

SIP message sent: REGISTER sip:robotics.net SIP/2.0
Call-ID: 1352416918007
CSeq: 1 REGISTER
From: <sip:[email protected]>;tag=1352416918018
To: <sip:[email protected]>
Via: SIP/2.0/WS Pof71HhIxUut.invalid;branch=z9hG4bK1352416917943;rport
Max-Forwards: 70
Expires: 3600
User-Agent: MobicentsWebRTCPhone
Allow: INVITE,UPDATE,ACK,CANCEL,BYE,NOTIFY,OPTIONS,MESSAGE,REFER
Contact: <sip:[email protected];transport=ws>
Content-Length: 0

 jain-sip.js:20682

StringMsgParser:parseSIPMessagebyte(): catched exception:TypeError: Cannot call 
method 'charCodeAt' of undefined jain-sip.js:11994

Uncaught TypeError: Cannot call method 'getContentLength' of null 
jain-sip.js:15406

The Parsing of the Contact Header for a replicated dialog is failing because 
the data replicated contains the Header Name

Unexpected internal error  null
java.lang.NullPointerException
    at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
    at gov.nist.javax.sip.parser.NioPipelineParser.readMessageBody(NioPipelineParser.java:293)
    at gov.nist.javax.sip.parser.NioPipelineParser.readStream(NioPipelineParser.java:230)
    at gov.nist.javax.sip.parser.NioPipelineParser.addBytes(NioPipelineParser.java:338)
    at gov.nist.javax.sip.stack.NioTcpMessageChannel.addBytes(NioTcpMessageChannel.java:122)
    at gov.nist.javax.sip.stack.NioTcpMessageChannel.readChannel(NioTcpMessageChannel.java:92)
    at gov.nist.javax.sip.stack.NioTcpMessageProcessor$ProcessorTask.read(NioTcpMessageProcessor.java:126)
    at gov.nist.javax.sip.stack.NioTcpMessageProcessor$ProcessorTask.run(NioTcpMessageProcessor.java:311)
    at java.lang.Thread.run(Thread.java:662)


I slighly changed examples.tls.Shootme to use TCP instead of TLS (does not 
really matter) and defined there 
gov.nist.javax.sip.TCP_POST_PARSING_THREAD_POOL_SIZE = 10

JS error getQop() on null object in 
HeaderFactoryImpl.prototype.createAuthorizationHeaderargu2()

See http://java.net/jira/browse/JSIP-425

In SIPTransactionStack.prototype.getHostAddress()
if(logger!=undefined)   
logger.debug("SIPTransactionStack:getHostAddress()"+stackAddress);
stackAddress is undefined, bad copy/paste

See http://java.net/jira/browse/JSIP-436

See Ticket 30866

What steps will reproduce the problem?

The Call Flow Tested is:

  Jain Sip UA                                                    Remote UA (SIPP)
      |                                                              |
      |                                                              |
      |                        INVITE  (1)                           |
      | -----------------------------------------------------------> |
      |                                                              |
      |                                                              |
      |                    200 OK INVITE  (2)                        |
      |                with Header Contact: [CONTACT_VALUE_1]        |
      | <----------------------------------------------------------- |
      |                                                              |
      |                                                              |
      |                        ACK  (3)                              |
      |         with Request-Line: INVITE [CONTACT_VALUE_1] SIP/2.0  |
      | -----------------------------------------------------------> |
      |                                                              |
      |                   ***** Call Established ****                |
      |                                                              |
      |                                                              |
      |                      Re-INVITE  (4)                          |
      |     with Request-Line: INVITE [CONTACT_VALUE_1] SIP/2.0      |
      | -----------------------------------------------------------> |  
      |                                                              |
      |                                                              |
      |                     200 OK Re-INVITE (5)                     |
      |              with Header Contact: [CONTACT_VALUE_2]          |   
      | <----------------------------------------------------------- |  
      |                                                              |
      |                                                              |
      |                 ACK  (6)                                     |
      |     with Request-Line: INVITE [CONTACT_VALUE_2] SIP/2.0      |   
      |  ----------------------------------------------------------> |
      |                                                              |
      |                                                              |
      |                      BYE  (7)                                |
      |     with Request-Line: INVITE [CONTACT_VALUE_2] SIP/2.0      |
      | -----------------------------------------------------------> |  
      |                                                              |
      |                                                              |
      |                     200 OK BYE (8)                           |
      | <----------------------------------------------------------- |  


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

 Considering the Rfcs:
   - RFC 3261 chapter 12.2.1.2:  
        When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present.
   - RFC 6141 chapter 4.5: UA Updating the Dialog's Local Target in a Response.
        A UA processing an incoming target refresh request can update its local target by returning a reliable provisional response or a 2xx response to the target-refresh request. The response needs to         contain the updated local target URI in its Contact header field. On sending the response, the UA can consider the target refresh operation completed.

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

Tested on the current version of jain-sip

Please provide any additional information below.

Proposed patch:

Save the remote Target Uri (when receiving 200 OK INVITE):

Add this code at line 3385 of gov.nist.javax.sip.stack.SIPDialog:

ContactList contactList = sipResponse.getContactHeaders();
if (contactList != null) {
  this.setRemoteTarget((ContactHeader) contactList.getFirst());
}

The remote target uri will be save and it seems that works.

Main issue here 
http://code.google.com/p/commscale/issues/detail?id=1&thanks=1&ts=1334935661

When processing a response, if the ClientTransaction detects a modification of 
the to-tag, it will spawn a new Dialog. This could happen by example if Alice 
would Invite a forking proxy whom would 180ring Bob but finally 200Ok on Carol. 
In this scenario, Alice's application layer might have difficulty to find back 
its context because the applicationData provided on the initial Dialog had been 
lost since the dialog had been overriden by the stack.

Only WS tranport protocol is implemented

LexerCore:match(): To: <tel:+33681672592>

Expecting  >>>43<<< got >>>+<<< jain-sip.js:2299
LexerCore.match jain-sip.js:2299
URLParser.global_phone_number jain-sip.js:12662
URLParser.parseTelephoneNumber jain-sip.js:12645
URLParser.telURL jain-sip.js:12748
URLParser.uriReference jain-sip.js:12581
AddressParser.nameAddr jain-sip.js:12995
AddressParser.address jain-sip.js:13051
AddressParametersParser.parse jain-sip.js:12173
ToParser.parse jain-sip.js:13115
StringMsgParser.processHeader jain-sip.js:11996
StringMsgParser.parseSIPMessagestring jain-sip.js:11803
StringMsgParser.parseSIPMessage jain-sip.js:11743
WSMsgParser.parsermessage jain-sip.js:15247
websocket.onmessage

See http://code.google.com/p/sipservlets/issues/detail?id=179

See http://java.net/jira/browse/JSIP-426

Implement SIP keepalive to keep up the websocket connection

When no certificates are installed and a TLS connections is received, the 
handshake fails. After the handshake failing the socket is not cleaned and the 
created channel is stored in the incomingMessageChannels causing it not to be 
GC'ed.

All this causes a memory leak, which after some connections produces an OOME.

A proposed fix is attached.

Reopening issue from http://code.google.com/p/mobicents/issues/detail?id=2942. 
We need to reverse the condition, fix the test and fix the whole jsip-ha 
testsuite which can be very useful.

http://java.net/jira/browse/JSIP-362

and 

http://code.google.com/p/mobicents/issues/detail?id=3188

We have a case where failover is enabled and Virtual IP Addresses setup.
Both Engines are setup on ip ending in 39 and 40.
When call is started on Engine, it uses 39 for outbound then a failover occurs
RE INVITE comes in the second engine and call is proxied outbound is using 40 
now.

Tied to https://telestax.zendesk.com/tickets/30981 

http://java.net/jira/browse/JSIP-394

Allows send and receive of keepalives as defined in RFC 5626 on the NIO branch 
like it is done for BIO

test.unit.gov.nist.javax.sip.stack.ReconnectTCPTest.testReconnectTCP has been 
failing

bad parsing of product/version list

Test JAIN SIP JS against Bowser WebRTC Browser for iOS and Android 
https://labs.ericsson.com/apps/bowser

using the locateHops(URI uri) method of 
org.mobicents.ext.javax.sip.dns.DefaultDNSServerLocator
Here is the DNS information i'm using in my test:
jag.com.               IN SOA  ns.jag.com.         hostmaster.jag.com. (
                                                2012082801
                                                10800
                                                3600
                                                604800
                                                86400 )

jag.com.               IN NS     ns.jag.com.

ns.jag.com.         IN A       142.120.93.49

server1.jag.com.              IN A       142.120.93.49
server1.jag.com.              IN A       127.0.0.1
server2.jag.com.              IN A       127.0.0.1

_sip._udp.jag.com. 86400 IN SRV 1 100 5060 server1.jag.com.
_sip._udp.jag.com. 86400 IN SRV 0 100 5070 server2.jag.com.
_sip._tcp.jag.com. 86400 IN SRV 0 100 5060 server1.jag.com.
_sip._tcp.jag.com. 86400 IN SRV 0 100 5070 server2.jag.com.

jag.com. IN NAPTR 100 10 "S" "SIP+D2U" "" _sip._udp.jag.com.
jag.com. IN NAPTR 101 10 "S" "SIP+D2T" "" _sip._tcp.jag.com.


When I resolve jag.com, jain-sip-ext gives me 2 different results which each 
contain two hops :

Uri: sip:[email protected] resulted in hops: [127.0.0.1:5070/udp, 127.0.0.1:5060/udp]
or
Uri: sip:[email protected] resulted in hops: [127.0.0.1:5070/udp, 
142.120.93.49:5060/udp]

As a comparison, I also tested with the "jain-sip-rfc3263-router" and I get the 
expected three hops :

Uri: sip:[email protected] resulted in hops: [127.0.0.1:5070/UDP, 
142.120.93.49:5060/UDP, 127.0.0.1:5060/UDP]


This difference/bug is that the code only resolves one A record:

String hostAddress= InetAddress.getByName(resolvedName).getHostAddress();

versus looping through all A/AAAA records(like in the jain-sip-rfc3263-router).

final Set<ARecord> aRecords = resolver.lookupARecords(hop.getHost());

for (ARecord aRecord : aRecords) {
  final String ipAddress = aRecord.getAddress().getHostAddress();
  final Hop resolvedHop = new HopImpl(ipAddress, hop.getPort(), hop.getTransport());
  if (resolvedHops.contains(resolvedHop) == false) {
    resolvedHops.add(resolvedHop);
  }
}

final Set<AAAARecord> aaaaRecords = resolver.lookupAAAARecords(hop.getHost());

for (AAAARecord aaaaRecord : aaaaRecords) {
                           }
  final String ipAddress = aaaaRecord.getAddress().getHostAddress();
  final Hop resolvedHop = new HopImpl(ipAddress, hop.getPort(), hop.getTransport());
  if (resolvedHops.contains(resolvedHop) == false) {
    resolvedHops.add(resolvedHop);
  }
}

For reference, here are the revelant sections in the rfcs 3263 and 2782:

RCF 3263 :
   If the TARGET was not a numeric IP address, and no port was present
   in the URI, the client performs an SRV query on the record returned
   from the NAPTR processing of Section 4.1, if such processing was
   performed. [...] Irregardless
   of how the SRV records were determined, the procedures of RFC 2782,
   as described in the section titled "Usage rules" are followed,
   augmented by the additional procedures of Section 4.3 of this
   document.

RFC 2782 :
Usage rules

   A SRV-cognizant client SHOULD use this procedure to locate a list of
   servers and connect to the preferred one:

        Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
        QTYPE=SRV.

        If the reply is NOERROR, ANCOUNT>0 and there is at least one
        SRV RR which specifies the requested Service and Protocol in
        the reply:

            If there is precisely one SRV RR, and its Target is "."
            (the root domain), abort.

            Else, for all such RR's, build a list of (Priority, Weight,
            Target) tuples

            Sort the list by priority (lowest number first)

            Create a new empty list

            For each distinct priority level
                While there are still elements left at this priority
                level

                    Select an element as specified above, in the
                    description of Weight in "The format of the SRV
                    RR" Section, and move it to the tail of the new
                    list

            For each element in the new list

                query the DNS for address records for the Target or
                use any such records found in the Additional Data
                section of the earlier SRV response.

                for each address record found, try to connect to the
               (protocol, address, service).

        else

            Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A

            for each address record found, try to connect to the
           (protocol, address, service)