usnistgov / jsip Goto Github PK

Documentation does not explicitly prohibit this. Perusing the code, it looks like it should work.
However, deleteSipProvider() has an odd bit of code which, when the last provider is removed, causes SipTransactionStack::stopStack() to be invoked.

This seems wrong - shouldn't deleteSipProvider() invoke the higher-level stop() instead?
More to the point, shouldn't deleteSipProvider() not even care about this?

I'm not sure what the expected behavior is, but I see two issues:

1. Either we should formally allow creation of SipProviders after the SipStack has been started (implying that we remove the call to stopStack() when the last SipProvider is deleted), or we should formally deny creation of SipProviders after the stack has been started.
2. If we really want to stop the SipStack when the last SipProvider is deleted, we need to ensure we invoke the right stop method (maybe super.stopStack() is the right thing... it just doesn't seem that way).

Hi team of NIST
I would like to know if we can use the stack in commercial software , if yes do we have to pay fees.
If we dont have to pay fees then do we have to release source code for same?

I tried to understand license terms but it doesnt specify about commercial use

Hi,
I have a SipDialog whose lastTransaction is a SipServerTransactionImpl

The state is Completed state (because it received a 491 on a RE-INVITE) until a timer sets it to Terminated (according to RFC3261 page 127 I think).
I am trying to send a RE-INVITE before the timer is triggered, so it is blocked in the ReInviteSender at this line
452: ((SIPServerTransaction)SIPDialog.this.lastTransaction).waitForTermination();

When the timer is triggered the state changes to _TERMINATED but if the transport is not reliable (UDP), then the this.terminationSemaphore.release(); will never be called and the ReInviteSender will remains blocked in the semaphore forever

@Override
public void setState(int newState) {
    // Set this timer for connection caching
    // of incoming connections.
    if (newState == TransactionState._TERMINATED && this.isReliable()
            && (!getSIPStack().cacheServerConnections)) {
        // Set a time after which the connection
        // is closed.
        this.collectionTime = TIMER_J;
        this.terminationSemaphore.release();
    }

    super.setState(newState);

}

In fact I'm not sure about the good thing to do in that case for now I replaced the test with

if (newState == TransactionState._TERMINATED && (!isReliable() || (this.isReliable() && (!getSIPStack().cacheServerConnections)))) {

so the release is called also on UDP transport.

TCP SIP applications using Jain SIP can suffer from poor response times because its TCP sockets do not have Nagle's algorithm disabled.

There should at least be an option to set TCP_NODELAY for an application, but I think that TCP_NODELAY should be the default behavior. At the very least, there should be an option.

It's pretty easy to do. Socket instances just need newsock.setTcpNoDelay(true).

Edit: I'm willing to do the development on this if you want to add this feature.

Not possible to generate Javadoc (due to (c) copyright sign in the comments):

[javadoc] jsip/src/javax/sip/SipListener.java:4: error: unmappable character for encoding UTF8
[javadoc] * Copyright � 2003 Sun Microsystems, Inc. All rights reserved.
[javadoc] ^

[javadoc] Loading source files for package javax.sip.message...
[javadoc] 100 errors

If using Java 8...

The definition of SIPHeaderList#removeLast causes a compilation error with Java 21:

The change is due to the introduction of 'Sequenced Collections' in JDK 21 release notes, which added a removeLast method to the collections API that clashes with the definition in SIPHeaderList.

The error could be fixed by changing the definition of SIPHeaderList#removeLast to match the definition in the collections API, or by renaming the method.

Repro:

JAVA_HOME=<path to JDK 21> ant -Djavac.source=8 -Djavac.target=8 -Dsource.encoding=iso-8859-1 runtck

[jain-javac] /usr/local/google/home/cushon/src/jsip/src/gov/nist/javax/sip/header/ims/ServiceRouteList.java:37: error: removeLast() in SIPHeaderList cannot implement removeLast() in List
[jain-javac] public class ServiceRouteList extends SIPHeaderList<ServiceRoute> {
[jain-javac]        ^
[jain-javac]   return type void is not compatible with ServiceRoute
[jain-javac]   where E is a type-variable:
[jain-javac]     E extends Object declared in interface List

In the jsip version I'm using, supported protocols for TLS client are "SSLv3", "SSLv2Hello", "TLSv1". My application is configured for TLS v1.

Problem: During a handshake, Client Hello sends it's higher supported version which is TLS v1.2. Server should then respond TLS v1 so the client can adapt, as TLS v1.2 is not supported by my server. But That's not the case: TLS v1.2 is mentionned in the server hello response.

The result is the hadnshake is failing after certificat client key exchange with an error message send by server: TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Unknown).

I'm using an old version of Jain-SIP and I'll update it because it seems the current version is supporting TLS v1.2 but still, I prefer to put an issue on it because the problem is real and may still exist.

RFC format is c=
but in IceSdpUtils at line 179

mediaDescription.setConnection(sdpFactory.createConnection(
"IN", defaultAddress.getHostAddress(), addressFamily));

fix is exchange parameters:
mediaDescription.setConnection(sdpFactory.createConnection(
"IN", addressFamily, defaultAddress.getHostAddress()));

https://tools.ietf.org/html/rfc4566

Best regards

gov.nist.javax.sdp.fields.AttributeField.equals(Object that) throws NullPointerException if attributes having no name even though both are same.

Eg: Comparing two a=sendrecv attributes causes NullPointerException.

Suggestion, if both the attributes doesn't have a name , then no need of comparing it

Section 18.1.1 of RFC 3261 states:

"If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via MUST be changed."

Does the jsip stack support upgrading the transport protocol of a request from UDP to TCP as per the above text?

Hello,

I've run into an issue where after TCP IO exceptions, dialogs are not cleaned up. As a result, memory is accumulated until the process runs out of memory.
I'm using version v1.2.301 of jain-sip-ri. This issue is reproducible in my environment.

To reproduce it I try to send an INVITE to a TCP target that does not exist. This results in an exception looking like this:

javax.sip.SipException: Could not connect to /10.42.42.42:5060
    at gov.nist.javax.sip.stack.SIPClientTransactionImpl.sendRequest(SIPClientTransactionImpl.java:1069)
    at com.company.ps.media.sip.MessageSendingService.sendRequest(MessageSendingService.java:69)
    at com.company.ps.media.sip.MessageSendingService.sendNewClientTransactionRequest(MessageSendingService.java:91)
    at com.company.ps.b2bua.common.MessageSendingServiceWrapper.lambda$sendNewClientTransactionRequest$2(MessageSendingServiceWrapper.java:71)
    at java.util.concurrent.CompletableFuture$AsyncRun.run(Unknown Source)
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: Could not connect to /10.42.42.42:5060
    at gov.nist.javax.sip.stack.IOHandler.sendBytes(IOHandler.java:391)
    at gov.nist.javax.sip.stack.TCPMessageChannel.sendMessage(TCPMessageChannel.java:350)
    at gov.nist.javax.sip.stack.MessageChannel.sendMessage(MessageChannel.java:281)
    at gov.nist.javax.sip.stack.SIPTransactionImpl.sendMessage(SIPTransactionImpl.java:892)
    at gov.nist.javax.sip.stack.SIPClientTransactionImpl.sendMessage(SIPClientTransactionImpl.java:475)
    at gov.nist.javax.sip.stack.SIPClientTransactionImpl.sendRequest(SIPClientTransactionImpl.java:1062)
    ... 11 more

The exception reporting the connection error is fine. The problem is that the created dialog is never cleaned up. What happens is for dialog instances to keep getting added into the SipStackImpl.earlyDialogTable where they are never removed.

From what I can gather, it seems to be a related with the dialogState itself which is still at its initial value NULL_STATE (-1) after the exception and not changed at any later point in time.

My expectation would be that it if a dialog can not be established for any reason (regardless of transport) it is cleaned up after some time and all references to it are removed.

SIPServerTransactionImpl.java line 1452 you test the sdp from the final response and you must check the session description from provisional response.

/*

• The UAS MAY send a final response to the initial request before
• having received PRACKs for all unacknowledged reliable provisional responses,
• unless the final response is 2xx and any of the unacknowledged reliable provisional
• responses contained a session description. In that case, it MUST NOT send a final
• response until those provisional responses are acknowledged.
  */

As you put in description, an user agent can send a final response after an unacked provisional if the unacknowledged reliable provisional responses doesn't contained a session description.

RFC 3261 defines the contents of the Expires and Min-Expires headers in SIP as "an integral number of seconds (in decimal) between 0 and (2^32)-1".
(https://tools.ietf.org/html/rfc3261#section-20.19)
This can be represented as an unsigned 32-bit integer, but since java uses signed integers, only values up to (2^31)-1 can be used without errors.

In the usual time-related context, this wouldn't be much of a problem, since we're talking about absurdly high values anyway. However, 3GPP's MCX/MCPTT protocol, which is based on SIP, requires the maximum allowed value of 4,294,967,295 to be used in the Expires header for certain messages. The reasons for this are beyond me, but obviously those messages will cause trouble.

I fixed the problem for me, locally, by changing the types from int to long, and restricting input values to the correct range. Didn't have any problems since. I'll try to attach a PR (bear with me, I'm new to the github stuff). Note that the error starts with the JSIP API interface definitions, so those would need changes too, and I don't know if that's easily possible (license issues etc). Ultimately, I won't mind if you ignore this issue. I just wanted to inform you of this and propose a fix, since I saw there's still some activity in here (which is nice).

What is jain-sip-ri represent for ?

What is the mean for ri ? Thanks

Continuation from @murillo128 's pull request #13 . This needs some more work. There are multiple issues that can come up. A real unit test is needed

Hey!

log4j 1.2 is already reached end-of-life and isn't jsip should be updated to log4j 2?

Thanks.

Recently encountered this issue when attempting to stop the SipStack. It looks like a missing null check within the TCPMessageProcessor class when the socket fails to be created. In my case, the designated port was already in use, so we get a JVM bind error creating the listening port.

[SipManager|2214|E] 2018-01-25 11:47:17.704-05:00  SipManager<10, :[5071]> caught Exception<javax.sip.InvalidArgumentException: Address already in use: JVM_Bind> while starting
[SipManager|2214|E] 2018-01-25 11:47:17.704-05:00  javax.sip.InvalidArgumentException: Address already in use: JVM_Bind Message<Address already in use: JVM_Bind> Cause<java.net.BindException: Address already in use: JVM_Bind>
[SipManager|2214|E] 2018-01-25 11:47:17.704-05:00     gov.nist.javax.sip.SipStackImpl.createListeningPoint(SipStackImpl.java:1552)

If I call stop on the SipStack after this, a NullPointerException is thrown.

[SipManager|339C|E] 2018-01-25 11:47:18.494-05:00  Failed To Stop SipStack java.lang.NullPointerException
[SipManager|339C|E] 2018-01-25 11:47:18.494-05:00  java.lang.NullPointerException
[SipManager|339C|E] 2018-01-25 11:47:18.494-05:00     gov.nist.javax.sip.stack.TCPMessageProcessor.stop(TCPMessageProcessor.java:164)
[SipManager|339C|E] 2018-01-25 11:47:18.494-05:00     gov.nist.javax.sip.stack.SIPTransactionStack.removeMessageProcessor(SIPTransactionStack.java:2422)
[SipManager|339C|E] 2018-01-25 11:47:18.494-05:00     gov.nist.javax.sip.stack.SIPTransactionStack.stopStack(SIPTransactionStack.java:2110)
[SipManager|339C|E] 2018-01-25 11:47:18.494-05:00     gov.nist.javax.sip.SipStackImpl.stop(SipStackImpl.java:1711)

This interruption of the stop() leaves at least two (2) threads on the system related to the SipStack: EventScannerThread and Timer-n.

Reviewing the source, it looks like the TCPMessageProcessor is not checking that the socket is valid before calling close(). I suspect the socket is null because of the previous binding error.

I tried the same scenario with UDP ports and did not have the same issue. As a workaround, I found that a second call to stop() does close out the remaining threads.

The test doesn't pass when executed.

start gov.nist.javax.sip.parser.AcceptLanguageParserTest
Accept-Language:  da   
Encoded header = Accept-Language: da

Accept-Language: 
Encoded header = Accept-Language: 

Accept-Language: ,
Encoded header = Accept-Language: 

done gov.nist.javax.sip.parser.AcceptLanguageParserTest


testParser(gov.nist.javax.sip.parser.AcceptLanguageParserTest)  Time elapsed: 0.02 sec  <<< FAILURE!
junit.framework.AssertionFailedError: expected:<Accept-Language: 
> but was:<Accept-Language: 
>
	at junit.framework.Assert.fail(Assert.java:57)
	at junit.framework.Assert.failNotEquals(Assert.java:329)

Please consider dropping this repository and taking ownership of RestComm/jain-sip.

There are numerous forks of RestComm/jain-sip on Github and it has been the de-facto master of jsip for a long time. Commits in the SVN repo at Kenai have long been referencing pull requests and issues of RestComm/jain-sip. I'd consider it a major disaster to have two competing jsip repos.

Having RestComm/jain-sip as the master has the clear benefit that

• All forks on Github will still be based on the then de-jure official jsip
• All issues and pull requests in the commit log will refer to the correct links

I don't know if this has been up for discussion and dismissed earlier and if so I'm sorry.

Setup

Alice using TCP when communicating to the VIP (Virtual IP) of Bob

Scenario

1. Execute a SIP call
2. TCP socket is established between Alice and Bob
3. Failover of the VIP to a new Bob instance. New Bob instance isn't aware of currently opened sockets
4. Execute a SIP call
5. Alice reuses the previously opened TCP socket and receives TCP RST
6. No retries are sent.

Logs

[2021-02-26 13:55:18.486] DEBUG [CmdProcessor-14] enableTimeoutTimer gov.nist.javax.sip.stack.SIPClientTransactionImpl@ebea8133 tickCount 64 currentTickCount = -1 - (unknown.jul.logger:243)
[2021-02-26 13:55:18.486] DEBUG [CmdProcessor-14] sendBytes TCP local inAddr 10.136.20.138 remote inAddr 10.136.20.139 port = 5055 length = 1876 isClient true - (unknown.jul.logger:243)
[2021-02-26 13:55:18.492] DEBUG [TCPMessageChannelThread] IOException closing sock java.net.SocketException: Connection reset - (unknown.jul.logger:243)
[2021-02-26 13:55:18.493] DEBUG [TCPMessageChannelThread] Closing socket tcp:10.136.20.139:5055 - (unknown.jul.logger:243)
[2021-02-26 13:55:18.493] DEBUG [PipelineThread-1] Received CRLF - (unknown.jul.logger:243)
[2021-02-26 13:55:18.493] DEBUG [PipelineThread-1] KeepAlive Double CRLF received, sending single CRLF as defined per RFC 5626 Section 4.4.1 - (unknown.jul.logger:243)
[2021-02-26 13:55:18.493] DEBUG [PipelineThread-1] ~~~ setting isPreviousLineCRLF=false - (unknown.jul.logger:243)
[2021-02-26 13:55:18.495] DEBUG [TCPMessageChannelThread] Closing my parser gov.nist.javax.sip.parser.PipelinedMsgParser@4fba0b56 - (unknown.jul.logger:243)
[2021-02-26 13:55:18.495] DEBUG [TCPMessageChannelThread] Closing pipelinedmsgparser gov.nist.javax.sip.parser.PipelinedMsgParser@4fba0b56 threadname PipelineThread-1 - (unknown.jul.logger:243)
[2021-02-26 13:55:18.496] DEBUG [TCPMessageChannelThread] Closing client output stream java.net.SocketOutputStream@4b859679 - (unknown.jul.logger:243)
[2021-02-26 13:55:18.496] DEBUG [TCPMessageChannelThread] Closing TCP socket 10.136.20.139:5055 - (unknown.jul.logger:243)
[2021-02-26 13:55:18.496] DEBUG [TCPMessageChannelThread] removed Socket and Semaphore for key 10.136.20.139:5055 - (unknown.jul.logger:243)
[2021-02-26 13:55:18.496] DEBUG [TCPMessageChannelThread] Closing message Channel (key = tcp:10.136.20.139:5055)gov.nist.javax.sip.stack.TCPMessageChannel@29e6bf37 - (unknown.jul.logger:243)
[2021-02-26 13:55:18.496] DEBUG [TCPMessageChannelThread] Thread[TCPMessageChannelThread,5,CmdProcessor] removing tcp:10.136.20.139:5055 for processor /10.136.20.138:14466/tcp - (unknown.jul.logger:243)
[2021-02-26 13:55:18.496] DEBUG [TCPMessageChannelThread] Thread[TCPMessageChannelThread,5,CmdProcessor] Removing incoming channel tcp:10.136.20.139:5055 for processor /10.136.20.138:14466/tcp - (unknown.jul.logger:243)
[2021-02-26 13:55:18.496] DEBUG [TCPMessageChannelThread] Closing pipelinedmsgparser gov.nist.javax.sip.parser.PipelinedMsgParser@4fba0b56 threadname PipelineThread-1 - (unknown.jul.logger:243)
[2021-02-26 13:55:18.496] DEBUG [PipelineThread-1] thread ending for threadname PipelineThread-1 - (unknown.jul.logger:243)

The IOException is handled by ConnectionOrientedMessageChannel within the catch (IOException ex) at line 595.

Experiments

We've disabled gov.nist.javax.sip.CACHE_CLIENT_CONNECTIONS, it helps for new dialogs but we have the problems on an existing dialog where the SIP Option is sent to a stale TCP socket.

We've switched to NIO and we have the same behavior.

How Should We Handle It?

In SIPTransactionImpl, the retransmission is only activated when the connection is UDP. When using TCP, the error is caught silently. I see 2 options

• User starts a retransmission timer
• Jain-SIP retries when socket is RST.

Should it be fixed in Jain-SIP? What should we do?

This line calls String#getBytes without specifying an encoding. This can cause problems depending on the default encoding of the platform.

For example, if the default encoding is US-ASCII, the getBytes call will replace some (not representable) unicode characters with question marks.

See also RestComm/jain-sip/issues/111.

Hi,
I'm experiencing an issue in case of an altered SDP message having:

• Content-Length: 0
• double \r\n at the message end
• strict set at true

In this scenario StringMsgParser method of the JSIP library does not detect a wrong message. Follows an example:

INVITE sip:[email protected] SIP/2.0
From: "company" sip:[email protected];tag=35b8d8a74ca0f4e34e0adfa7_F10.101.6.120
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 15 INVITE
Via: SIP/2.0/UDP 10.101.6.120;branch=z9hG4bKf_169eac12baa17054e0adfb3_I
Content-Length: 0
Max-Forwards: 70
Contact: sip:[email protected];transport=udp
Content-Type: application/sdp
User-Agent: SIP
Supported: replaces

v=0
o=sip:[email protected] 1 16 IN IP4 10.101.6.120
s=sip:[email protected]
c=IN IP4 10.101.6.120
t=0 0
m=audio 5000 RTP/AVP 0 8 18 4 120
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000/1
a=rtpmap:120 telephone-event/8000/1
"\r\n at the end"

Is there any setting to be done or is it a fault in the library?

The StringMsgParser code at the StringMsgParser.java

// Check for content legth header
if (readBody && message.getContentLength() != null ) {
if ( message.getContentLength().getContentLength() != 0) {
int bodyLength = msgBuffer.length - i;

      byte[] body = new byte[bodyLength];
      System.arraycopy(msgBuffer, i, body, 0, bodyLength);
      message.setMessageContent(body,!strict,computeContentLengthFromMessage,message.getContentLength().getContentLength());
   } else if (!computeContentLengthFromMessage && message.getContentLength().getContentLength() == 0 & strict) {
       String last4Chars = new String(msgBuffer, msgBuffer.length - 4, 4);
       if(!"\r\n\r\n".equals(last4Chars)) {
           throw new ParseException("Extraneous characters at the end of the message ",i);
       }
   } 

does not detect the wrong message.

Is there anything that must be set or is it a library fault? Thanks

Hi,

Is there any plan to update to log4j 2.16.0 due to the log4shell vulnerability.

It may be possible to send a sip string containing the jni and execute code this way no?

https://nvd.nist.gov/vuln/detail/CVE-2021-44228

https://nvd.nist.gov/vuln/detail/CVE-2021-4104

Behind Istio that makes all HTTP headers it proxies to applications lowercase, this code here fails, it is using a HashMap and as a result is case sensitive.

https://github.com/usnistgov/jsip/blob/master/src/gov/nist/javax/sip/stack/WebSocketHttpHandshake.java#L114

Fails as it's looking for Sec-WebSocket-Key but the headers HashMap would have sec-websocket-key.

For example:

var test = new HashMap<String, String>();
test.put("sec-lower", "foo");
test.put("Sec-Upper", "bar");
System.out.println("Test: " + test.get("sec-upper"));
System.out.println("Test: " + test.get("sec-lower"));

Outputs:

Test: null
Test: foo

Interestingly other parts of the code seem to be case insensitively written, e.g.

https://github.com/usnistgov/jsip/blob/master/src/gov/nist/javax/sip/stack/WebSocketHttpHandshake.java#L85

So behind Istio or other proxies that lowercase headers the response Sec-WebSocket-Accept header is always of the value of the string null

I have encountered an issue recently within the MultipartMimeContentImpl. It appears that some specifically sized content can trigger a NoSuchElementException while the code is scanning through. Looking into how the scanner works, it seems that a specifically sized piece of content could be read into the buffer with the final region end bytes not read ("--\r\n" remains on the stream yet to be read). The pattern used by the Impl class considers them optional and matches the region. Since there are remaining bytes and there is a matching pattern in the buffer, the Scanner returns "true" that there is another element during the hasNext() check. Unfortunately, the Scanner reads in the final region end bytes, hits the EOF, and determines that there are no more elements (throwing the exception).

Seems like the easiest solution would be to try-catch the call to scanner.next() and breaking out of the loop when the exception is thrown. This may not account for conditions where the body content is malformed.

I have attached an example piece of body content that throws the exception when passed into the Impl.
jain-sip bad SIP body.txt

From profiling the jsip project, I have noticed that the String.intern use within SIPHeader's constructor is fairly CPU intensive - taking up 26%+ of the overall CPU time:

This has been noticed in other sip stack forks, albeit an attempted fix (moving to a hashmap) was reverted for an unknown reason.

Since there's only ever a handful of header names, and they are never compared with ==, is .intern() fully needed - or is there a better, less CPU intensive way of handling this?

Apologies if this has already been discussed and there's no desire to change it; I done some searching and couldn't see any mention, so thought I'd raise this issue incase it wasn't known.

According to https://github.com/usnistgov/jsip/blob/master/m2/android-jain-sip-ri/pom.xml there should be a "src/android" folder in the repo, but there is none.
As a result, the "examples" can't compile properly.

So two questions:

• why keeping the pom.xml file if there's no source code to build an artifact ?
• why keeping the an example using a supposed "android" stack which is nowhere ?

I read the README.txt file associated to the examples for an answer and even there, the provided link is dead:
To run this example, you need the android build of JAIN-SIP in the classpath. You can take the android build from here https://jsip.ci.cloudbees.com/job/android-jsip/

In the end: why not removing the test which has no additional value ? (not to mention than the README.txt To convert any example to android you simply put android prefix to the JAIN SIP packages. so basically, the ctest is redundent)

I have threading issue when using TCP. The issue arrives when jain sip stack sends the 1st SIP out via SipDialog.sendRequest:

(a) thread#1 executes: sendTCPMessage which calls sendBytes (clientSock = null -> openOutgoingConnection) -> writeChunks -> send
In "NioTcpMessageProcessor.send" at then end it will execute: selector.wakeup
(b) thread#2 wakes up since it is on selector.select and will execute write. In the write method line #214 nioHandler.getMessageChannel will return null and thus have a 'Dead socketChannel'
(c) thread#1 returns in sendTCPMessage and since sock != socketChannel 1st time it will excute:
nioHandler.putMessageChannel(sock, this);

But then this is too late. The 1st SipDialog.sendRequest is not sent out & the stack does not even retry because it does not detect this as a failure.
I have added myself a stack trace in the putMessageChannel to confirm that this is what happens.

siptcperror.log

The syntax for the P-Access-Network-Info contains a gen-value as a choice for access-info. gen-value is defined as "token / host / quoted-string". So the following header lines are syntactically OK but they will be rejected by the current parser implementation:

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=23456789ABCDE;"ip=123.123.123.123"
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=23456789ABCDE; [123:4::abcd]

I am trying to use call transfer. Caller endpoint is a test jsip implementation. Called endpoint is the mizu java sip client. jsip doesn't seems to send any SIP REFER message. Is call transfer implemented in this lib?

The library cannot be compiled with Java 8 compiler.

For example, one of the compilation errors:
[jain-javac] jsip/src/gov/nist/core/MultiMap.java:35: error: remove(Object,Object) in MultiMap clashes with remove(Object,Object) in Map
[jain-javac] public Object remove( Object key, Object item );
[jain-javac] ^
[jain-javac] return type Object is not compatible with boolean

As Java 8 added remove(Object,Object) method to Map class.
(also source/target value 1.5 is obsolete).

javax.net.ssl.SSLException: Received fatal alert: handshake_failure
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634)
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800)
at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1083)
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:907)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
at gov.nist.javax.sip.stack.SSLStateMachine.unwrap(SSLStateMachine.java:303)
at gov.nist.javax.sip.stack.SSLStateMachine.unwrap(SSLStateMachine.java:244)
at gov.nist.javax.sip.stack.NioTlsWebSocketMessageChannel.addBytes(NioTlsWebSocketMessageChannel.java:282)
at gov.nist.javax.sip.stack.NioTcpMessageChannel.readChannel(NioTcpMessageChannel.java:121)
at gov.nist.javax.sip.stack.NioTcpMessageProcessor$ProcessorTask.read(NioTcpMessageProcessor.java:154)
at gov.nist.javax.sip.stack.NioTcpMessageProcessor$ProcessorTask.run(NioTcpMessageProcessor.java:344)
at java.lang.Thread.run(Thread.java:745)

Registering to a server concurrently can start handshaking multiple times. We must make sure handshake is complete before allowing concurrency.

Hello, i noticed that a TCP transport doesn't work after version 1.2.324. I tried to register my sip account on different sip servers but result the same:
I send registration request to sip server, at this point everething is ok the sip server receives my request, after that sip server send me 401 Unauthorized response and when i received this response the registration process stucks and then nothing happens.
Sometimes (but very rarely) the registration process successfully complete but in this case after the registration i can't receive any calls or update or delete my registration it looks like sip stack stucks and due to this it can't handle any requests.
I also want to note that in the same cases everething works fine if i use an UDP transport.

3GPP allows multiple P-Access-Network-Info headers in a sip message. Currently stack doesn't have support for this

Today the JAIN stack does the request retransmissions (incase of SipClientTransactions) and also the response retransmissions (incase of SipServerTransactions).

It would be nice to have whether the request / response is retransmitted in the SipMessage object. and also log the message.

This helps for the application to keep track of retransmissions in log messages.

Thanks
Mahesh N

I discovered that an up to date version of the jain sip javadoc no longer seems to be hosted online. The link here no longer works: https://www.cloudbees.com/dev-error

So, I got the sources here and tried to build them. Unfortunately, the vast majority of javadocs do not to build. I get numerous errors along these lines:
[javadoc] /Users/brenmill/wprojects/wx2/jsip/src/javax/sip/TransactionTerminatedEvent.java:4: error: unmappable character for encoding UTF8
[javadoc] * Copyright � 2003 Sun Microsystems, Inc. All rights reserved.
[javadoc] ^

It seems that the source files are not in utf-8; however, the ant javadoc task does not pass the proper encoding in. In current versions of javadoc this breaks the build.

Please add the encoding attribute to all javadoc ant commands. e.g. encoding="${source.encoding}"

There already exists a PR RestComm/jain-sip#75. Since there's no reply there, I'm raising one here. Can we have the same feature here ? If so, I can make exact changes and raise one here.
Thanks

There are quite a lot bug of fixes done in RestComm/jain-sip. I can see the same authors of unistgov/jsip have done fixes in restcomm/jain-sip. why those are not ported to this repo?. The new users of this repo (who doesn't know restcomm) either has to do the fixes themselves (which would be re-inventing the wheel) or use the restcomm directly. which makes this repo unusable.
@vladimirralev do you know the reason? restcomm repo looks like abandoned by authors as no PR/issues from community are acknowledged.

withdrawn

If you add a header with a non-empty value to a message containing the same header with an empty value, the result is an incorrectly formatted message. For example, given an existing message of:

...
Supported:
...

Adding a "Supported: timer" header to that message results in the following:

...
Support: ,timer
...

It's a reasonable expectation for the value to be "Supported: timer" after adding the new header, since it's effectively overwriting the initial empty value of "no extensions are supported" as specified in RFC 3261, section 20.37.

Ara there any main page for this project at NIST ? https://www.nist.gov/

What are the www directory for ?

I found some JAIN SIP API introduction at Oracle, http://www.oracle.com/technetwork/java/introduction-jain-sip-090386.html

Thanks

JSLEE 1.1 specifies (14.4.1 Requirements of the SLEE Vendor) that implementations must support the loading and instantiation of management clients implemented as MLet MBeans.

javax.management.loading.MLet and the other interface/classes related to "advanced dynamic loading" were deprecated, for removal since Java SE 20.

Would it be possible to confirm that the maintainers of the JSLEE specification are aware that MLets are obsolete and will be removed in a future Java SE / JDK release?

Is there a team or someone working on:

• making this project Java 11 compliant
• making a proper maven directory structure and usage

I've been following this repo for years now, and I worked with JSIP during 7 years (and by the way I must thank you guys for all the great work you're doing), and still I can't get it: why not moving to maven and why still using java 1.5 as a target (cf. https://github.com/usnistgov/jsip/blob/master/ant-build-config.properties) ??

I'm probably kicking a open door, so I apologize in advance, again: I sincerly think you're doing a great job with this lib.

Encountered if supplying a javax.net.ssl.trustStore and NOT supplying a javax.net.ssl.keyStorePassword

Caused by: java.lang.NullPointerException at gov.nist.core.net.DefaultSecurityManagerProvider.init(DefaultSecurityManagerProvider.java:98) at gov.nist.javax.sip.SipStackImpl.<init>(SipStackImpl.java:1133)

if(trustStoreFilename != null) {
	final KeyStore ts = KeyStore.getInstance(trustStoreType);
	ts.load(new FileInputStream(new File(trustStoreFilename)), trustStorePassword.toCharArray());
	
	trustManagerFactory.init((KeyStore) ts);
} else {
	trustManagerFactory.init((KeyStore)null);
}

A -> B : 102 re-invite
B -> A : 2 re-invite
B -> A : 102 491 request pending
A -> B : 2 491 request pending
A -> B : 2 ACK
B -> A : 102 ACK

The ack B -> A : 102 ACK, gets dropped by the stack ( for A).

After looking the code in Dialog.java , It looks like the lastInviteResponseCSeqNumber is intended to be used for matching the incoming ACK cSeq. However, lastInviteResponseCSeqNumber gets updated even for incoming response. So, When the ACK comes in for the outgoing response, it fails to match the lastInviteResponseCSeqNumber and it gets dropped.

As per the latest update by RFC 7913 for P-Access-Network-Info header, the allowed values of extension-access-info is updated
from
extension-access-info = gen-value
to
extension-access-info = generic-param

As per RFC 3261
gen-value = token / host / quoted-string
&
generic-param = token [ EQUAL gen-value ]

It restricts the header such as
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=23456789ABCDE; "a=b"

As "a=b" does not follow generic-param format.

Notes:-
As per the RFC 7913,

As the P-Access-Network-Info header field is mainly used in networks
defined by the 3rd-Generation Partnership Project (3GPP), where new
values following the 'generic-param' rule have been defined
[TS.3GPP.24.229], the update is not considered to cause issues with
backward compatibility.

In reality this causes some backward compatibility issues as I mentioned above. I think this is ok and we have to consider the latest format which is as per 3GPP standards.

I have a fix which meets the latest standards. I can push it if the reviewer considers this change is necessary.

I was testing our voip java application with jain-sip-sdp-1.2.111. After two months,parsing didnt happened because of nesting_level had gone minus value.i just checked source code.it seems that nesting_level variable are static variable.

The jsip\src\examples\ims\build.xml is confirgured with wrong paths to log4j_jar and junit_jar.

Current value
<property name="log4j_jar" value="${root}/lib/${log4j}" /> <property name="junit_jar" value="${root}/lib/${junit}" />

And it has to be

<property name="log4j_jar" value="${root}/${log4j}" /> <property name="junit_jar" value="${root}/${junit}" />

The folder lib is already added in ant-build-config.properties

Dear Sirs,
We are using the library as per subject version and we are noticing a fault when the indicated library parse the body of SIP message MESSAGE (SMS).
When in the body of SIP message there are characters equal or greater than 0x80 they are translated by library with 3F

Supposing that the body of SMS in input to the library is:
00 02 00 07 91 14 70 80 00 65 78 12 11 02 0c 91 24 60 80 32 84 86 00 00 ff 04 d4 f2 9c 0e
The output from library is:
00 02 00 07 3f 14 70 3f 00 65 78 12 11 02 0c 3f 24 60 3f 32 3f 3f 00 00 3f 04 3f 3f 3f 0e
91,80,84,86,ff,d4,f2,9c -> 3F

I have searched among the library the known issues but was not able to find any reference.