Now the parameter of SIP RA listerning port is hardcored now. Let's do it easier configurable.

Your requirement is that not only DB will rollback but also the JSLEE Transaction that executes the event will rollback on DB error

I want them to work in synergy - as they do when in JTA/JCA.

This feature is needed when we create new Dialog (ClientDialogWrapper) with DialogActivity getNewDialog(Address from, Address to) method:

DialogActivity caleeDialog = getSleeSipProvider().getNewDialog(remoteParty, localParty);
caleeDialog.terminateOnBye(false);

Now we have exception because wrappedDialog is null:

https://github.com/RestComm/jain-slee.sip/blob/master/resources/sip11/ra/src/main/java/org/mobicents/slee/resource/sip11/wrappers/ClientDialogWrapper.java#L545

Solution is caching terminateOnBye before we can set wrappedDialog.terminateOnBy():

https://github.com/RestComm/jain-slee.sip/blob/master/resources/sip11/ra/src/main/java/org/mobicents/slee/resource/sip11/wrappers/DialogWrapper.java#L679

Hi,

Testing this SipRA (V 7.1.21), the following occurs:
Given a just established session (INVITE->18x->200->ACK), the test program waits 2 seconds and subsequently issues a BYE. This BYE is not seen/handled by the RA (although the SIP stack gets it) so no 200 OK is generated in return by the application under test and the test fails.

On waiting approx. 8-10 seconds before sending the BYE, it is handled by the RA and thus the application generates the 200 OK and the test succeeds.

See captures.zip for the wireshark/SIP traces of both tests.

From this log it looks like BYE's will only get through after cleanup of a timer on this transaction, related to MobicentsHASIPServerTransaction.

Can anyone confirm this, explain this or have a solution ?

Thansk in advance,
Tom.

Have a look at :

https://github.com/RestComm/jain-slee.sip/blob/master/resources/sip11/ra/src/main/java/org/mobicents/slee/resource/sip11/SleeSipProviderImpl.java#L163-L165

Shouldn't be there:
SipUri sipURI = localSipURIs.get(transport); ?

When new dialog is creating with SleeSipProvider.getNewDialog(Address from, Address to) it is ClientDialogWrapper object. And when new request is creating with ClientDialogWrapper.createRequest(String methodName) and the real dialog doesn't exist yet so it act like it will build such a dialog when sending this request. But in this case request have not Contact header.

There is an issue withing jain-sip-ri causing unexpected restransmissions of the provisional responses with additional content or headers. Please see:
RestComm/jain-sip#151

Implementation of GracefullyStopableResourceAdaptor interface as to support SLEE feature described here:
RestComm/jain-slee#75

I think DialogWrapper.createRequest(Request) removes top route header incorrectly. It checks if the top header host/port equals to current listening point IP and port and if it match, then it is removed.

This works if route header in the incoming INVITE contains IP address, but if it contains host name (e.g. Route: sip:as.open-ims.test;lr) then the route is not removed which typically result in endless loop because same request gets forwarded again to the AS. It is quite a common case to use host names instead of IP addresses and use DNS based configuration in IMS environments.

Based on SIP strict/loose routing rules I think the top route header could always be removed if it contains "lr" parameter. Otherwise it should be left as is. If you think this is not safe then it would be a nice to have feature to disable the removal of topmost route header so that this could be consistent and could be done in the service level.

Patch for proposed solution:
route-issue.patch.zip

In the case of INVITE + REINVITE callflow, second ACK is always dropped and last response is resent.

Callflow (https://tools.ietf.org/html/rfc3665#page-61):

S       [email protected]      CSeq:1 INVITE   INVITE sip:[email protected]:5066 SIP/2.0
R       [email protected]      CSeq:1 INVITE   SIP/2.0 100 Trying
R       [email protected]      CSeq:1 INVITE   SIP/2.0 180 Ringing
R       [email protected]      CSeq:1 INVITE   SIP/2.0 200 OK
S       [email protected]      CSeq:1 ACK      ACK sip:[email protected]:5066 SIP/2.0
S       [email protected]      CSeq:2 INVITE   INVITE sip:[email protected]:5066 SIP/2.0
R       [email protected]      CSeq:2 INVITE   SIP/2.0 100 Trying
R       [email protected]      CSeq:2 INVITE   SIP/2.0 200 OK
S       [email protected]      CSeq:2 ACK      ACK sip:[email protected]:5066 SIP/2.0 => dropped
R       [email protected]      CSeq:2 INVITE   SIP/2.0 200 OK                      => 200 OK resent
S       [email protected]      CSeq:2 ACK      ACK sip:[email protected]:5066 SIP/2.0
S       [email protected]      CSeq:3 BYE      BYE sip:[email protected]:5066 SIP/2.0
R       [email protected]      CSeq:3 BYE      SIP/2.0 200 OK

SIPP TC is attached.
REINVITE.zip

Regards,
ThE-MaRaC

Why in RA, there is "udp" transport added by default?

https://github.com/RestComm/jain-slee.sip/blob/master/resources/sip11/ra/src/main/java/org/mobicents/slee/resource/sip11/SipResourceAdaptor.java#L224

If one chooses to use only TCP transport, then UDP transport still will be present anyway in transports. After RA initialization transports contains ('UDP','TCP') and two listening points will be created (for TCP and UDP).

raActive():
https://github.com/RestComm/jain-slee.sip/blob/master/resources/sip11/ra/src/main/java/org/mobicents/slee/resource/sip11/SipResourceAdaptor.java#L1255-L1264

This brings an issue when retrieving listening point:
https://github.com/RestComm/jain-slee.sip/blob/master/resources/sip11/ra/src/main/java/org/mobicents/slee/resource/sip11/wrappers/ClientDialogWrapper.java#L425

Since map doesn't have an order defined, then getting one random entry from the map makes Contact header contain sometimes UDP instead of desired TCP.

Some details:

org.mobicents.slee.resource.sip11.SleeSipProviderImpl:

    public ListeningPoint getListeningPoint() {
        checkState();
        return this.provider.getListeningPoint();
    }

gov.nist.javax.sip.SipProviderImpl.getListeningPoint():

    public ListeningPoint getListeningPoint() {
        if (this.listeningPoints.size() > 0) {
            return ((ListeningPoint) this.listeningPoints.values().iterator().next());
        }

        return null;
    }

listeningPoints will have UDP, TCP transports. and getListeningPoint() will return most likely UDP (most likely, since it depends per map behaviour, in my case it is always UDP).

For me it looks like a bug.

The javax.sip.Transaction interface defines applicationData methods, used to store transaction specific data:

• public void setApplicationData(Object o);
• public Object getApplicationData();

The current base wrapper implemetation throws SecurityException.

    /**
     * Operation forbidden in the sip interfaces implemented by concrete wrappers.
     * @return
     */
    public Object getApplicationData() {
        throw new SecurityException();
    }

    /**
     * Operation forbidden in the sip interfaces implemented by concrete wrappers.
     * @param arg0
     */
    public void setApplicationData(Object arg0) {
        throw new SecurityException();
    }

Methods are not overriden in wrapper classes for client and server transactions.
Only the ACKDummyTransaction overrides applicationData methods
https://github.com/RestComm/jain-slee.sip/blob/master/resources/sip11/ra/src/main/java/org/mobicents/slee/resource/sip11/wrappers/ACKDummyTransaction.java

I recommend an enhancement through the implementation of those methods for Transaction extended interfaces.

At present sipra.properties are loaded the following way:
https://github.com/RestComm/jain-slee.sip/blob/master/resources/sip11/ra/src/main/java/org/mobicents/slee/resource/sip11/SipResourceAdaptor.java#L1219

This is inconvinient, since any change to the file requires extracting sipra.properties from jar, modifying it and then updating jar file. More over, if multiple sipra.properties are available in a classpath, then the one closer to SipResourceAdaptor class will be chosen.

As an enhancement, optional RA configuration property should be added which will allow to specify location of the sipra.properties file. If property not specified, then the default file should be chosen.

First step: to integrate the Restcomm Statistics in SIP RA only.
Second step: to integrate the Restcomm Statistics as JSLEE Core facility (that all RAs can get and increment either calls, seconds or/and messages yes so that each RAs doesn't have to instantiate their own RestcommStatsReporter).

During a run of one of the tests from 3rd party application, NullPointerException is thrown on dialog delete(). The test focused on invoked bye in dialog creation before receiving a response.

From the source code:
https://github.com/RestComm/jain-slee.sip/blob/master/resources/sip11/ra/src/main/java/org/mobicents/slee/resource/sip11/wrappers/DialogWrapper.java#L503-L506

Seems like existance of wrappedDialog is checked (line 503) on current status retrieval, but later on (line 505) it is not cheked (!wrappedDialog.isServer()) and also wrappedDialog.delete() is invoked.

This leads to NullPointerException.

From my understanding and from the rfc, the call ID should be different of both A and B leg of 1 sip call.. I've taken the logs generated by running the sipb2bua example, and the call id is same for both. Isn't this an issue?

Invite packet from A to server:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP 172.30.128.75:41071;branch=z9hG4bK-1003163100;rport=41071;received=172.30.128.75
From: sip:[email protected]:5060;tag=536107915
To: sip:[email protected]
Contact: sip:[email protected]:41071;transport=tcp;+g.oma.sip-im;language="en,fr";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Call-ID: 3a8f3345-9fdb-2140-4221-ddda22de9545
CSeq: 443837939 INVITE
Content-Type: application/sdp
Max-Forwards: 70
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
Allow: INVITE,ACK,CANCEL,BYE,MESSAGE,OPTIONS,NOTIFY,PRACK,UPDATE,REFER
Privacy: none
P-Access-Network-Info: ADSL; utran-cell-id-3gpp=00000000
User-Agent: IM-client/OMA1.0 android-ngn-stack/v2.586.1328 (doubango r1328 - Nexus 6P)
P-Preferred-Identity: sip:[email protected]:5060
Supported: 100rel
Content-Length: 507
....sdp content....

Invite Packet from server to B leg:
INVITE sip:[email protected]:46825 SIP/2.0
CSeq: 443837939 INVITE
Content-Type: application/sdp
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
Allow: INVITE,ACK,CANCEL,BYE,MESSAGE,OPTIONS,NOTIFY,PRACK,UPDATE,REFER
Privacy: none
P-Access-Network-Info: ADSL; utran-cell-id-3gpp=00000000
User-Agent: IM-client/OMA1.0 android-ngn-stack/v2.586.1328 (doubango r1328 - Nexus 6P)
P-Preferred-Identity: sip:[email protected]:5060
Supported: 100rel
Max-Forwards: 70
Call-ID: 3a8f3345-9fdb-2140-4221-ddda22de9545
From: sip:[email protected]:5060;tag=64b45f34
To: sip:[email protected]
Via: SIP/2.0/TCP 172.30.128.75:41071;branch=z9hG4bK-1003163100;rport=41071;received=172.30.128.75
Contact: sip:[email protected]:41071;transport=tcp
Content-Length: 507
...sdp content....

after activating the second one we get:
L
08:38:20,964 ERROR SipResourceAdaptor error in initializing resource adaptor
java.util.TooManyListenersException: Stack already has a listener. Only one listener per stack allowed
at gov.nist.javax.sip.SipProviderImpl.addSipListener(SipProviderImpl.java:221)
at org.mobicents.slee.resource.sip11.SipResourceAdaptor.raActive(SipResourceAdaptor.java:1271)
at org.mobicents.slee.resource.ResourceAdaptorObjectImpl.raActive(ResourceAdaptorObjectImpl.java:255)
at org.mobicents.slee.resource.ResourceAdaptorEntityImpl.activate(ResourceAdaptorEntityImpl.java:374)
at org.mobicents.slee.container.management.ResourceManagementImpl.activateResourceAdaptorEntity(ResourceManagementImpl.java:275)
at org.mobicents.slee.container.management.jmx.ResourceManagementMBeanImpl.activateResourceAdaptorEntity(ResourceManagementMBeanImpl.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)

This maybe an actual slee isssue, since classloading may be affecting the initialization

It is not possible to provide own CACHE_CLASS since RA on raActive() hardcodes specific class name.

In the SipResourceAdaptor.java file you can find block like:
// define impl of the cache of the HA stack
properties.setProperty(ClusteredSipStack.CACHE_CLASS_NAME_PROPERTY,SipResourceAdaptorMobicentsSipCache.class.getName());`

Reason:
I would like to mock this class on for some unit testing, but current implementation of the RA limits that.

After invoking sendCancel on Dialog Activity we are getting associated ACI through ACI factory.

When we does that we get javax.slee.UnrecognizedActivityException. It is visible from the server.log that SIP RA tries to send CANCEL as the same transaction as related INVITE. CANCEL should be handled in a separate transaction.

getNewDialogActivityClientTransaction method creates a new ClientTransactionWrapper bound to a DialogWrapper, which is not an activity in SLEE. This comment means that if we use getNewDialogActivityClientTransaction method than we don't add ClientTransaction activity object in SLEE and cannot obtain the ActivityContextInterface for it.
But we can use another getNewClientTransaction method for this purpose.

Hi,
I have this error when i try to reproduce the sip registar jdbc example:

ERROR [SbbEntityImpl] (SLEE-EventRouterExecutor-1-thread-1) Failed to assign and create sbb object java.lang.ClassCastException: org.mobicents.slee.resource.jdbc.JdbcResourceAdaptorSbbInterfaceImpl cannot be cast to org.restcomm.slee.resource.jdbc.JdbcResourceAdaptorSbbInterface

Someone can help me to fix that.

this is derived from ticket 34725

The simplest way to reproduce:

• Start the SLEE container without any deployed application
• send OPTIONS message to sip stack
• Observe (in SLEE console) that no activity is created in the SLEE, as expected
• Deploy the supplied SLEE DU jar (which will start listening and responding to SIP OPTIONS)
• Send OPTIONS message to sip stack
• Observe that SIP activites are termianted properly in SLEE console (not leaking)
• Undeploy the supplied SLEE DU jar
• Send OPTIONS message to sip stack
• Observe that SIP activites are created but not termianted (leaking)

Rootcause is found:

Seems we have a bug at

https://github.com/RestComm/jain-slee.sip/blob/master/resources/sip11/ra/src/main/java/org/mobicents/slee/resource/sip11/EventIDFilter.java#L49

the condition check for the map containing key is true with the fresh slee-container case.
But after install and remove service. the key added with value 0 (means having 0 servive to fire event)

the correct condition should be

return !(eventID2serviceIDs.containsKey(eventType.getEventType()) && !eventID2serviceIDs.get(eventType.getEventType()).isEmpty());