Add support for Mobile Equipment Identity Check Procedure consisting of ME-Identity-Check-Request (ECR) and ME-Identity-Check-Answer (ECA) diameter messages use by S13 (between MME and EIR) and S13’ (SGSN and EIR) reference points.
Both S13 and S13’ interfaces use same application id 16777252. The diameter command code is 324
For more information refer to chapter 6 of 3GPP TS 29.272

Mobicents Diameter Stack should support the updated Diameter Base Protocol, as of RFC 6733.

This issue should serve as an umbrella issue for the several changes introduced (for which individual issues should be created) and a placeholder for it's general discussion.

As specified in in 3GPP TS 29.219:

The Sy reference point is located between the Policy and Charging Rules Function (PCRF) and the Online Charging System (OCS). The Sy reference point enables transfer of information relating to subscriber spending from OCS to PCRF and supports the following functions:

• Request of policy counter status reporting from PCRF to OCS.
• Notification of policy counter status change from OCS to PCRF.
• Cancellation of policy counter status reporting from PCRF to OCS.

Since the Sy interface resides between PCRF and OCS in the HPLMN, roaming with home routed or visited access as well as non-roaming scenarios are supported in the same manner.
The stage 2 level requirements for the Sy reference point are defined in 3GPP TS 23.203.
Signalling flows related to the Sy interface are specified in 3GPP TS 29.213.
Diameter overload control procedures over the Sy interface defined in Annex G of 3GPP TS 29.213.
Diameter message priority mechanism procedures over the Sy interface defined in Annex J of 3GPP TS 29.213.

Diagram below portrays LTE E-UTRAN/EPC/IMS interface, including Sy interface.

Looking at org.jdiameter.common.impl.validation.DictionaryImpl you may find it's impossible to get original AVP type from dictionary with

        // UTF8String and Time are special situations, we don't want to convert these.
        if (typeParent == null || typeParent.equals("") || typeName.equals("UTF8String") || typeName.equals("Time")) {
          typeParent = typeName;
        }

and

            avpType = avpDefnChildElement.getAttribute("type-name");
            //FIXME: baranowb: why this is like that? This changes type of AVP to primitive ONE..? Checks against type dont make sense, ie to check for Address type...
            avpType = typedefMap.get(avpType);

As a result I cannot convert AVP into different format because I don't have type of this AVP (like it's an Address?).

May I suggest adding String getOriginalType(); to org.jdiameter.api.validation.AvpRepresentation so anyone who interested in original type could get it?

Enums are also not included into AvpRepresentation. Shouldn't we add it?

When deploying mobicents-diameter-mux-1.6.0.FINAL.sar on jboss 7.2.0final or EAP6.2 we obtain the error :
[2:02:56 PM] Antoine Michéa: Caused by: java.lang.NoClassDefFoundError: org/jboss/system/ServiceMBean
[2:03:01 PM] Antoine Michéa: Caused by: java.lang.ClassNotFoundException: org.jboss.system.ServiceMBean from [Module "deployment.mobicents-diameter-mux-1.6.0.FINAL.sar:main" from Service Module Loader]
at org.jboss.mod
[2:03:28 PM] Antoine Michéa: pb avec le deploy du dernier sar visiblement
[2:03:50 PM] Antoine Michéa: WARN [org.jboss.modules](MSC service thread 1-2) Failed to define class org.mobicents.diameter.stack.DiameterStackMultiplexerMBean in
Module "deployment.mobicents-diameter-mux-1.6.0.FINAL.sar:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/mobicents/di
ameter/stack/DiameterStackMultiplexerMBean (Module "deployment.mobicents-diameter-mux-1.6.0.FINAL.sar:main" from Service Module Loader)

Currently the stack has basic support for SCTP. It should be investigated what (if anything) is required to support SCTP Multi-Homing feature and implement it.

Hi,

I found a file descriptor leak after a network breakdown. The root cause is socketChannel.connect(destAddress) in TCPTransportClient.java. I got this exception on Red Hat Enterprise Linux Server release 7.1 (Maipo) during breakdown:

org.jdiameter.client.api.io.TransportException: Cannot init transport:
        at org.jdiameter.client.impl.transport.tcp.TCPClientConnection.connect(TCPClientConnection.java:111)
        at org.jdiameter.client.impl.controller.PeerImpl$ActionContext.connect(PeerImpl.java:685)
        at org.jdiameter.server.impl.fsm.PeerFSMImpl$4.processEvent(PeerFSMImpl.java:378)
        at org.jdiameter.client.impl.fsm.PeerFSMImpl$3.run(PeerFSMImpl.java:207)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.ConnectException: Connection refused
        at sun.nio.ch.Net.connect0(Native Method)
        at sun.nio.ch.Net.connect(Net.java:454)
        at sun.nio.ch.Net.connect(Net.java:446)
        at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
        at org.jdiameter.client.impl.transport.tcp.TCPTransportClient.initialize(TCPTransportClient.java:131)
        at org.jdiameter.client.impl.transport.tcp.TCPClientConnection.connect(TCPClientConnection.java:107)

When receiving DWA from a peer, the timeout event and the DWA event are coming almost at the same time, which causes the peer to be disconnected. Two threads are doing it at the same time, which we have a race condition. You can see the log that 2 threads are executing the Event, and the Timeout.

2016-11-02 23:50:46,475 DEBUG [PeerFSMImpl] (Thread-14) Handling event with type [DWA_EVENT]
2016-11-02 23:50:46,475 DEBUG [PeerFSMImpl] (Thread-14) Not performing validation to message since validator is DISABLED.
2016-11-02 23:50:46,475 DEBUG [PeerFSMImpl] (Thread-14) Placing event [Event{name:DWA_EVENT, key:aaa://10.225.20.206:16018, object:MessageImpl{commandCode=280, flags=0}}] into linked blocking queue with remaining capacity: [10000].
2016-11-02 23:50:46,475 DEBUG [PeerFSMImpl] (FSM-SPeer{Uri=aaa://10.225.20.206; State=null; con=null; incConnull }_2-1) SPeer{Uri=aaa://10.225.20.206; State=OKAY; con=org.jdiameter.server.impl.io.sctp.SCTPServerConnection@162db65b; incCon{} } FSM switch state: OKAY -> SUSPECT
2016-11-02 23:50:46,477 DEBUG [PeerFSMImpl] (FSM-SPeer{Uri=aaa://10.225.20.206; State=null; con=null; incConnull }_10-9) Got Event [Event{name:DWA_EVENT, key:aaa://10.225.20.206:16018, object:MessageImpl{commandCode=280, flags=0}}] from Queue
2016-11-02 23:50:46,478 DEBUG [PeerFSMImpl] (FSM-SPeer{Uri=aaa://10.225.20.206; State=null; con=null; incConnull }_10-9) Process event [Event{name:DWA_EVENT, key:aaa://10.225.20.206:16018, object:MessageImpl{commandCode=280, flags=0}}]. Peer State is [OKAY]
2016-11-02 23:50:55,466 DEBUG [TimerTask] (SLEE-TimerFacility-thread-3) Task with id -6ee284d6:158250d0338:-7fbb is recurring, not removing it locally nor in the cluster
2016-11-02 23:50:55,466 DEBUG [TimerTask] (SLEE-TimerFacility-thread-3) Firing Timer with id -6ee284d6:158250d0338:-7fbb
2016-11-02 23:50:55,466 DEBUG [TimerFacilityTimerTask] (SLEE-TimerFacility-thread-3) Executing task with timer ID -6ee284d6:158250d0338:-7fbb
2016-11-02 23:50:55,466 DEBUG [TimerFacilityTimerTask] (SLEE-TimerFacility-thread-3) Delay till execution is 1
2016-11-02 23:50:55,466 DEBUG [TimerFacilityTimerTask] (SLEE-TimerFacility-thread-3) Remaining executions:2147483647
2016-11-02 23:51:15,519 DEBUG [PeerFSMImpl] (FSM-SPeer{Uri=aaa://10.225.20.206; State=null; con=null; incConnull }_8-7) Sending timeout event
2016-11-02 23:51:15,520 DEBUG [PeerFSMImpl] (FSM-SPeer{Uri=aaa://10.225.20.206; State=null; con=null; incConnull }_8-7) Handling event with type [TIMEOUT_EVENT]
2016-11-02 23:51:15,520 DEBUG [PeerFSMImpl] (FSM-SPeer{Uri=aaa://10.225.20.206; State=null; con=null; incConnull }_8-7) Not performing validation to message since validator is DISABLED.
2016-11-02 23:51:15,520 DEBUG [PeerFSMImpl] (FSM-SPeer{Uri=aaa://10.225.20.206; State=null; con=null; incConnull }_8-7) Placing event [Event{name:TIMEOUT_EVENT, key:null, object:null}] into linked blocking queue with remaining capacity: [10000].
2016-11-02 23:51:15,520 DEBUG [PeerFSMImpl] (FSM-SPeer{Uri=aaa://10.225.20.206; State=null; con=null; incConnull }_8-7) Got Event [Event{name:TIMEOUT_EVENT, key:null, object:null}] from Queue
2016-11-02 23:51:15,520 DEBUG [PeerFSMImpl] (FSM-SPeer{Uri=aaa://10.225.20.206; State=null; con=null; incConnull }_8-7) Process event [Event{name:TIMEOUT_EVENT, key:null, object:null}]. Peer State is [SUSPECT]
2016-11-02 23:51:15,520 DEBUG [SCTPServerConnection] (FSM-SPeer{Uri=aaa://10.225.20.206; State=null; con=null; incConnull }_8-7) Disconnecting SCTP Server Connection aaa://10.225.20.206:16018

Hi

During profiling we found that many logger objects are made as local objects, so are re-created wasting lots of processing.

Suggest that you replace all:
protected Logger
with
protected final static Logger

Everywhere in the project.

Enhancement of the jDiameter stack according to https://telestax.zendesk.com/hc/en-us/requests/33156

Basic functionality is to add load balancing among peers and failover of Diamtere traffic in case peer is not available.
Failover for protocols errors according to RFC 6733, failover for ongoing session according to RFC 4006.

Diameter-based SLh interface implementation for Control Plane LCS for LTE according to 3GPP TS 29.173.

Tied with issue: RestComm/gmlc#2

Using ThreadGroup is not recommended and it has already brought some problems. It's usage should be replaced and references to it (docs, config) removed.

Add support for (re)creating a Diameter lost/non-existing session, for instance, when receiving and UPDATE_EVENT or TERMINATE_EVENT CCR for a non-existing session.

Move all the IO layer to Netty.

• TCP
• TLS
• SCTP : we can use the Netty-2 branch of https://github.com/Restcomm/sctp/tree/netty-2 and corresponding release from CI Job https://mobicents.ci.cloudbees.com/job/Restcomm-SCTP-Netty/. this should also solve #25

Either in 3GPP TS 29.172 (SLg) as in 3GPP TS 32.299 (where it is specified) it is defined as OctetString. Here the extract from 3GPP TS 32.299 (last release, 14.1.0)

7.2.94 Location-Estimate AVP
The Location-Estimate AVP (AVP code 1242) is of type OctetString and contains an estimate of the location of an MS in universal coordinates and the accuracy of the estimate. Refers to the geographical area description in TS 23.032 [227] for the internal structure and encoding of this AVP.

Currently, Location-Estimate AVP is defined as UTF8String, surely as in previous releases of 3GPP TS 32.299 (e.g. 8.9.0), Location-Estimate was defined as UTF8String, but that is outdated and prevents compliance for SLg interface implementation, as it reuses it as OctetString.

Other references:
http://developingsolutions.com/DiaDict/Dictionary/Location-Estimate.html

Follow up from #35

Interface between HSS and 3GPP AAA Server (SWx-interface)
This reference point is located between 3GPP AAA Server and HSS and is used for transport of authentication data. This interface is specified in 3GPP TS 29.273

This issue is copied from googlecode (Issue 71 in jdiameter: shutdown problem with TCP under Tomcat)

What steps will reproduce the problem?
1.Configure for TCP
2.Run as webapp under tomcat
3.shutdown tomcat.

What is the expected output? What do you see instead?
Tomcat is not able to stop due to org.jdiameter.server.impl.io.tcp.NetworkGuard's Executor (binder) which is never shuted down.

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

Please provide any additional information below.
You should call binder.shutdown() in e.g. cleanTask.

Here is our patch:

--- "a/3parties\\JDiameter\\core\\jdiameter\\impl\\src\\main\\java\\org\\jdiameter\\server\\impl\\io\\tcp\\NetworkGuard.java"
+++ "b/3parties\\JDiameter\\core\\jdiameter\\impl\\src\\main\\java\\org\\jdiameter\\server\\impl\\io\\tcp\\NetworkGuard.java"
@@ -275,6 +275,9 @@ public class NetworkGuard implements INetworkGuard {
         }
         serverSocket = null;
       }
+      if (binder != null) {
+        binder.shutdown();
+      }
     }

     @Override

When connected to 2 DRAs, the traffic shall be sent to the originator if still OK, and then try the second one. So, currently the message delivery will select the peer based on the list of peers obtained from the configuration:

1. Peer dra1.realm.com for realm.com
2. Peer dra2.realm.com for realm.com
   So, when reading the selectedPeer, the stack will load using the realm, and simply use the first from the list of peers obtained, not being always the originator of the message. It should select the peer that originated the message.

Mobicents jDiameter Stack has minimal support for functional nodes other than Server or Client, such as Relay, Proxy, Redirect and Translation. This support should be improved and create some tests/examples to exemplify on how to use it in Mobicents jDiameter Stack.

Hi,

It seems like there is wrong reference here http://docs.telestax.com/category/diameter/ -> step2. There is reference to bitbucket (https://[email protected]/telestax/telscale-diameter.git), but maybe it should be updated to https://github.com/RestComm/jdiameter/ ?

In most SIP+Diameter scenarios it should be required that the related SIP and Diameter messages for the same session are delivered to the same node (colocation).

For such behavior it is needed to create a specific algorithm for the Mobicents Load Balancer capable of interpret and relate SIP and Diameter messages.

Currently timeouts are not passed to the application, leaving to the SLEE application to use other ways to detect those (eg, setting timers). A SLEE event type should be implemented in order to deliver the actual stack timeout.

Possibly Diameter application specific timer events should also be implemented (eg, Tx and Tcc in DCCA), but, if so, should be out of scope of this issue.

SCTP lib is updating after adding new functionality into JSS7 stack. Now we have newer versions with netty support and we need to make support for them into jdiameter.

We have a case in which the Jdiameter is sending a CEA message for a CER message asking about support for 10415 applications, however, the CEA contains ALL supported features. Inside the CEA, by default the Cx states support for both 10415 and 13019. However the server that sent the CER complaints about the duplicity. We have been reading the RFCs, and the 6733 (https://tools.ietf.org/html/rfc6733#section-5.3) states the following:

The receiver of the Capabilities-Exchange-Request (CER) MUST
determine common applications by computing the intersection of its
own set of supported Application Ids against all of the
Application-Id AVPs (Auth-Application-Id, Acct-Application-Id, and
Vendor-Specific-Application-Id) present in the CER. The value of the
Vendor-Id AVP in the Vendor-Specific-Application-Id MUST NOT be used
during computation. The sender of the Capabilities-Exchange-Answer
(CEA) SHOULD include all of its supported applications as a hint to
the receiver regarding all of its application capabilities.

Could we have a way to limit the responses on the CEA to follow the first statement, and limit the supported applications to the ones that intersect? Could it be a configuration? What do you think? Is it worth checking?

Interface between ePDG and Untrusted non-3GPP Access (SWn-interface)
This is the reference point between the Untrusted Non-3GPP IP Access and the ePDG. Traffic on this interface for a UE-initiated tunnel has to be forced towards ePDG. This interface is specified in 3GPP TS 29.273

SLs interface implementation for LTE Location Services; LCS Application Protocol (LCS-AP) between the MME and E-SMLC according to 3GPP TS 29.171.

One thing I have noted is that unless Diameter activities are ended by their state machine (e.g. a CCR-T message is received) the activities never expire and there is no way for the SBB to remove them.

In the event of (non-Mobicents!) Diameter clients malfunctioning or rebooting this can cause a memory leak.

e.g.
Diameter Gx Client sends CCR-INIT for a certain IP address with session ID ABC
Diameter Gx Client malfunctions and sends CCR-INIT for the same IP address with session ID DEF
Gx Client never every terminate session ID ABC and it stays forever and is never free-ed.

The SBB application actually knows that session ID ABC needs to be removed when it receives a CCR-INIT for the same IP.

If you edit the Diameter GX RA by adding to GxServerSessionActivityImpl.java:

public void delayedEndActivity() {
this.setTerminateAfterProcessing(true);
super.baseListener.startActivityRemoveTimer(getActivityHandle());

}

And to GxServerSessionActivity.java

void delayedEndActivity();

The SBB can explicitly end an activity if it needs to by calling delayedEndActivity on the activity.

This could be applied to all session based Diameter RAs

If the CER message received contains IP addresses, those are ignored to generate the information for the Peer, and the FQDN is used instead. When the CER contains IP addresses, those shall be used to construct the Peer IP information.
The Peer shall have a list of IPs, as to allow multiple paths.

When deploying mobicents-diameter-mux-1.6.0.FINAL.sar on jboss 7.2.0final or EAP6.2 we obtain the error :
Caused by: java.lang.NoClassDefFoundError: org/jboss/system/ServiceMBean
Caused by: java.lang.ClassNotFoundException: org.jboss.system.ServiceMBean from [Module "deployment.mobicents-diameter-mux-1.6.0.FINAL.sar:main" from Service Module Loader]
at org.jboss.mod
WARN [org.jboss.modules](MSC service thread 1-2) Failed to define class org.mobicents.diameter.stack.DiameterStackMultiplexerMBean in
Module "deployment.mobicents-diameter-mux-1.6.0.FINAL.sar:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/mobicents/di
ameter/stack/DiameterStackMultiplexerMBean (Module "deployment.mobicents-diameter-mux-1.6.0.FINAL.sar:main" from Service Module Loader)

When I run example server and example client i has error .
0 [main] DEBUG com.xkeam.example.diameter.ExampleServer - log4j configured
4 [main] INFO com.xkeam.example.diameter.ExampleServer - Initializing Stack...
SLF4J: The requested version 1.5.8 by your slf4j binding is not compatible with [1.6, 1.7]
SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further details.
77 [main] INFO com.xkeam.example.diameter.ExampleServer - AVP Dictionary successfully parsed.
296 [main] INFO org.jdiameter.client.impl.StackImpl - (-)(-)(-)(-)(-) Starting Mobicents DIAMETER Stack v1.7.0.106 (-)(-)(-)(-)(-)
Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.format(Ljava/lang/String;Ljava/lang/Object;)Ljava/lang/String;
at org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:223)
at org.jdiameter.common.impl.controller.AbstractPeer.createPeerStatistics(AbstractPeer.java:88)
at org.jdiameter.client.impl.MetaDataImpl$ClientLocalPeer.(MetaDataImpl.java:242)
at org.jdiameter.server.impl.MetaDataImpl$ServerLocalPeer.(MetaDataImpl.java:154)
at org.jdiameter.server.impl.MetaDataImpl.newLocalPeer(MetaDataImpl.java:104)
at org.jdiameter.client.impl.MetaDataImpl.(MetaDataImpl.java:122)
at org.jdiameter.server.impl.MetaDataImpl.(MetaDataImpl.java:94)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at org.picocontainer.injectors.AbstractInjector.newInstance(AbstractInjector.java:147)
at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:332)
at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:272)
at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:354)
at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:692)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:646)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:632)
at org.picocontainer.parameters.BasicComponentParameter$1.resolveInstance(BasicComponentParameter.java:105)
at org.picocontainer.parameters.ComponentParameter$1.resolveInstance(ComponentParameter.java:136)
at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:76)
at org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:299)
at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:325)
at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:272)
at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:354)
at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:692)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:646)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:671)
at org.jdiameter.client.impl.helpers.AssemblerImpl.getComponentInstance(AssemblerImpl.java:152)
at org.jdiameter.client.impl.StackImpl.init(StackImpl.java:166)
at com.xkeam.example.diameter.ExampleServer.initStack(ExampleServer.java:115)
at com.xkeam.example.diameter.ExampleServer.main(ExampleServer.java:244)

All the code is newest , i clone it today , and not change any thing , Pls help me

Hi all,

I have some issue, which looks strange to me. Could you have a look into?

I'm trying to send CER message to our Cisco diameter server. According to log file, which I'm getting, CER is received from Cisco side and CEA was replied back to my jdiameter client. For some reason, jdiameter client is not able to process

it in right way and keep trying to send CER (my listener is never called back). Please look at in attached log file, configuration of my jdiameter client and source code. My jdiameter client is very simple and straightforward.

Java client: http://textuploader.com/a2mnf
Configuration of Java client: http://textuploader.com/a2mn2
Log file: http://textuploader.com/a2mnn

Thanks,
Anatoly

The following issues have been found while trying to use the JMX stack configuration.

1. Local Peer add IP Address
   _LocalPeer_addIPAddress("127.0.0.1").
   Will trow:
   java.lang.UnsupportedOperationException
   at java.util.AbstractList.add(AbstractList.java:148)
   at java.util.AbstractList.add(AbstractList.java:108)
   at org.mobicents.diameter.stack.DiameterStackMultiplexer._LocalPeer_addIPAddress(DiameterStackMultiplexer.java:545)
2. Network peers
   There is no method to retreive the existing list, so there is not an easy way to delete them.
3. Stack status
   There is not status indicator for the stack, so by simply calling stopStack there is no way knowing is that worked.
4. getRealms from Network realms
   The method _Network_Realms_getRealms will only return the realms associated with the first result, which shall return all realms.

Currently the peer selection is based on the rating of a peer in a certain realm. Different load-balancing techniques should be possible, such as round-robin, evaluating certain AVP values, etc.

These algorithms should be an extension point for the Mobicents Diameter Stack.

For SMS over LTE, like mentioned in RestComm/smscgateway#85, it will be crucial also to fully implement Gy interface between OCS and and PCEF (Policy and Charging Enforcing Function), analog to Ro interface, already implemented. Diameter messages for Gy are defined in 3GPP TS 32.299, charging architecture and principles in 3GPP TS 32.240, Packet-Switched domain charging in 3GPP TS 32.251.

When receiving CER events with a list of matching app-ids, the loop will not set correctly the requested values, and will not accept the incoming connection. So, we have created a map to hold all the CER requested vendor App-id, and be able to match them. Previously, the code will overwrite the each time the vendor id, so only the last one will be used.

We solved the issue by adding a hasmap:
This set will hold the information
Set vendorIds = new HashSet<>();

The existing code is:

public List<ApplicationId> getApplicationIdAvps() {
    if (this.applicationIds != null) {
      return this.applicationIds;
    }
    List<ApplicationId> rc = new ArrayList<ApplicationId>();
    try {
      AvpSet authAppId = avpSet.getAvps(Avp.AUTH_APPLICATION_ID);
      for (Avp anAuthAppId : authAppId) {
        rc.add(ApplicationId.createByAuthAppId((anAuthAppId).getInteger32()));
      }
      AvpSet accAppId = avpSet.getAvps(Avp.ACCT_APPLICATION_ID);
      for (Avp anAccAppId : accAppId) {
        rc.add(ApplicationId.createByAccAppId((anAccAppId).getInteger32()));
      }
      AvpSet specAppId = avpSet.getAvps(Avp.VENDOR_SPECIFIC_APPLICATION_ID);
      for (Avp aSpecAppId : specAppId) {
        long vendorId = 0, acctApplicationId = 0, authApplicationId = 0;
        AvpSet avps = (aSpecAppId).getGrouped();
        for (Avp localAvp : avps) {
          if (localAvp.getCode() == Avp.VENDOR_ID) {
            vendorId = localAvp.getUnsigned32();
          }
          if (localAvp.getCode() == Avp.AUTH_APPLICATION_ID) {
            authApplicationId = localAvp.getUnsigned32();
          }
          if (localAvp.getCode() == Avp.ACCT_APPLICATION_ID) {
            acctApplicationId = localAvp.getUnsigned32();
          }
        }
        if (authApplicationId != 0) {
          rc.add(ApplicationId.createByAuthAppId(vendorId, authApplicationId));
        }
        if (acctApplicationId != 0) {
          rc.add(ApplicationId.createByAccAppId(vendorId, acctApplicationId));
        }
      }
    }
    catch (Exception exception) {
      return new ArrayList<ApplicationId>();
    }

    this.applicationIds = rc;
    return this.applicationIds;
  }

The new code is:

public List<ApplicationId> getApplicationIdAvps() {
  if (this.applicationIds != null) {
    return this.applicationIds;
  }
  List<ApplicationId> rc = new ArrayList<ApplicationId>();
  try {
    AvpSet authAppId = avpSet.getAvps(Avp.AUTH_APPLICATION_ID);
    for (Avp anAuthAppId : authAppId) {
      rc.add(ApplicationId.createByAuthAppId((anAuthAppId).getInteger32()));
    }
    AvpSet accAppId = avpSet.getAvps(Avp.ACCT_APPLICATION_ID);
    for (Avp anAccAppId : accAppId) {
      rc.add(ApplicationId.createByAccAppId((anAccAppId).getInteger32()));
    }
    AvpSet specAppId = avpSet.getAvps(Avp.VENDOR_SPECIFIC_APPLICATION_ID);
    for (Avp aSpecAppId : specAppId) {
      long vendorId = 0, acctApplicationId = 0, authApplicationId = 0;
      Set<Long> vendorIds = new HashSet<>();
      AvpSet avps = (aSpecAppId).getGrouped();
      for (Avp localAvp : avps) {
        if (localAvp.getCode() == Avp.VENDOR_ID) {
          vendorId = localAvp.getUnsigned32();
          vendorIds.add(vendorId);
        }
        if (localAvp.getCode() == Avp.AUTH_APPLICATION_ID) {
          authApplicationId = localAvp.getUnsigned32();
        }
        if (localAvp.getCode() == Avp.ACCT_APPLICATION_ID) {
          acctApplicationId = localAvp.getUnsigned32();
        }
      }
      if (authApplicationId != 0) {
        for (Long vendId : vendorIds) {
          rc.add(ApplicationId.createByAuthAppId(vendId, authApplicationId));
        }
      }
      if (acctApplicationId != 0) {
        for (Long vendId: vendorIds) {
          rc.add(ApplicationId.createByAccAppId(vendId, acctApplicationId));
        }
      }
    }
  }
  catch (Exception exception) {
    return new ArrayList<ApplicationId>();
  }

  this.applicationIds = rc;
  return this.applicationIds;
}

Interface between ePDG and 3GPP AAA Server/proxy (SWm-interface)
This reference point is located between 3GPP AAA Server/Proxy and ePDG and is used for AAA signalling (transport of mobility parameters, tunnel authentication and authorization data). This reference point also includes the MAG-AAA interface functionality and Mobile IPv6 NAS-AAA interface functionality. This interface is specified in 3GPP TS 29.273.

Mobicents jDiameter Stack has minimal support for functional nodes other than Server or Client, such as Relay, Proxy, Redirect and Translation. This support should be improved and create some tests/examples to exemplify on how to use it in Mobicents jDiameter Stack.

Currently there's little developer documentation related to Mobicents jDiameter Stack/MUX.

It should be improved with more detailed explanation of the components, flows and examples on how to develop on top of Mobicents jDiameter Stack.

Mobicents jDiameter Stack has minimal support for functional nodes other than Server or Client, such as Relay, Proxy, Redirect and Translation. This support should be improved and create some tests/examples to exemplify on how to use it in Mobicents jDiameter Stack.

https://github.com/RestComm/jdiameter/blob/master/core/jdiameter/impl/src/main/resources/META-INF/LICENSE-LGPL-2.1.TXT it should be AGPL

Currently the TLS support in Diameter stack is somewhat "proprietary", based mostly on the way RFC 6733 specifies, and it's known to work properly between two jDiameter instances but not so much with other stack implementations.

This should be revised and made available in both modes (RFC 3588 and RFC 6733), being defined by configuration (if possible, on a per peer basis).

It should be tested against other implementations (freeDiameter, seagull, etc).

This issue is copied from googlecode (Issue 77 in jdiameter: Avoid BufferOverflowException)

What steps will reproduce the problem?

1. Use client with high through output (600 TPS and each message ~1 KB) and TCP connection
2. Stop and start Diameter server

What is the expected output? What do you see instead?
Expected: no exception and the connection is restored automatically. I get many BufferOverflowException and the connection lost.

What version of the product are you using? On what operating system?
1.6.0.FINAL CentOS 7

Please provide any additional information below.
When I added an extra condition into append(byte[]) in TCPTransportClient class I got the expected behavior.

--- "a/3parties\\JDiameter\\core\\jdiameter\\impl\\src\\main\\java\\org\\jdiameter\\client\\impl\\transport\\tcp\\TCPTransportClient.java"
+++ "b/3parties\\JDiameter\\core\\jdiameter\\impl\\src\\main\\java\\org\\jdiameter\\client\\impl\\transport\\tcp\\TCPTransportClient.java"
@@ -345,7 +345,7 @@ public class TCPTransportClient implements Runnable {
    * @param data data to add
    */
   private void append(byte[] data) {
-    if (storage.position() + data.length >= storage.capacity()) {
+    if (storage.position() + data.length >= storage.capacity() || data.length > storage.remaining()) {
       ByteBuffer tmp = ByteBuffer.allocate(storage.limit() + data.length * 2);
       byte[] tmpData = new byte[storage.position()];
       storage.flip();

With the current SCTP version of the library used on the diameter, there is a hard limit on the buffer size for the SCTP message. When the buffer is smaller than the message, the exception is not well handled, so, an exception will be thrown:
2016-09-19 13:03:52,839 ERROR SelectorThread Error while selecting the ready keys
java.nio.BufferOverflowException
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:357)
at java.nio.ByteBuffer.put(ByteBuffer.java:832)
at org.mobicents.protocols.sctp.AssociationImpl.write(AssociationImpl.java:611)
at org.mobicents.protocols.sctp.SelectorThread.write(SelectorThread.java:436)
at org.mobicents.protocols.sctp.SelectorThread.run(SelectorThread.java:157)
at java.lang.Thread.run(Thread.java:745)
And the message on the next iteration willl be sent.

We are using the stack to send the SAR message with a big XML (8000bytes), so its not working:
We had to patch the SCTP library with new values:

// The buffer into which we'll read data when it's available
private ByteBuffer rxBuffer = ByteBuffer.allocateDirect(16384);
private ByteBuffer txBuffer = ByteBuffer.allocateDirect(16384);

Do you plan to upgrade the SCTP library?

The Local peer shall allow defining multiple realms to enable hosting multiple-realms. Currently, only 1 realm is allowed, so, we have to use a DRA to translate everything into a unique realm.

Mobicents jDiameter Stack has minimal support for functional nodes other than Server or Client, such as Relay, Proxy, Redirect and Translation. This support should be improved and create some tests/examples to exemplify on how to use it in Mobicents jDiameter Stack.

Hi

We've found a possible memory leak for Diameter session based RAs (e.g. Rx, Ro, Gx). I want to see if the dev team agrees before raising it as a bug fix.

Looking just at Ro:
org.jdiameter.server.impl.app.ro.ServerRoSessionImpl.java

For CCA-U has Result-Code != SUCCESS the state machine does the following:

case SENT_UPDATE_RESPONSE:

RoCreditControlAnswer answer = (RoCreditControlAnswer) localEvent.getAnswer();
try {
if(isSuccess(answer.getResultCodeAvp().getUnsigned32())) {
// Current State: OPEN
// Event: CC update request received and successfully processed
// Action: Send CC update answer, debit used units, reserve new units, restart Tcc
// New State: OPEN
startTcc(answer.getValidityTimeAvp());
else {
// Current State: OPEN
// Event: CC update request received but not successfully processed
// Action: Send CC update answer with Result-Code != SUCCESS, debit used units
// New State: IDLE
// It's a failure, we wait for Tcc to fire -- FIXME: Alexandre: Should we?
}

Seen as how startTcc() is an empty method there doesn't seem to be any timer functionality. So if an CCA-U has Result-Code != SUCCESS the activity stays in OPEN, never returns to IDLE and is never released.

I tested and this prevents the memory leak.

            // It's a failure, we wait for Tcc to fire -- FIXME: Alexandre: Should we?

•                                newState = ServerRoSessionState.IDLE;
                           }
                       } catch (AvpDataException e) {
                           throw new InternalException(e);
                       }
                       dispatchEvent(localEvent.getAnswer());
  

•           if(newState != null) {
  

•                        setState(newState);
  

•       }
                      break;
  

This is for ServerRoSessionImpl.java.

The same should be done for all session based RAs (ServerGxSessionImpl.java, ServerRxSessionImpl.java)

For instance, on each message send, the following is performed:

long timeOut = container.getConfiguration().getLongValue(MessageTimeOut.ordinal(), (Long) MessageTimeOut.defValue());

Behaviors like this should be replaced by storing the configuration value in a local variable.

SLg interface implementation for LTE Location Services; Evolved Packet Core (EPC) LCS Protocol (ELP) between the GMLC and the Mobile Management Entity (MME) according to 3GPP TS 29.172.

Tied with issue: RestComm/gmlc#2

Hi all,

We have found 2 concurrency issues with AVP encoding/decoding when doing load tests.

1. Ecoding problem causes such exceptions:

2015-08-14 13:47:23,832 DEBUG [org.jdiameter.client.impl.controller.PeerImpl] (TCPReader-1) internalError
org.jdiameter.client.api.io.TransportException: Avp Data Exception:
        at org.jdiameter.client.impl.transport.tcp.TCPClientConnection.onEvent(TCPClientConnection.java:319)
        at org.jdiameter.client.impl.transport.tcp.TCPClientConnection.onAvpDataException(TCPClientConnection.java:276)
        at org.jdiameter.client.impl.transport.tcp.TCPTransportClient.seekMessage(TCPTransportClient.java:446)
        at org.jdiameter.client.impl.transport.tcp.TCPTransportClient.append(TCPTransportClient.java:392)
        at org.jdiameter.client.impl.transport.tcp.TCPTransportClient.run(TCPTransportClient.java:213)
        at java.lang.Thread.run(Thread.java:745)
Caused by: org.jdiameter.api.AvpDataException: org.jdiameter.api.AvpDataException: Not enough data in buffer!
        at org.jdiameter.client.impl.parser.MessageParser.createMessage(MessageParser.java:121)
        at org.jdiameter.client.impl.transport.tcp.TCPClientConnection.onEvent(TCPClientConnection.java:314)
        at org.jdiameter.client.impl.transport.tcp.TCPClientConnection.onMessageReceived(TCPClientConnection.java:271)
        at org.jdiameter.client.impl.transport.tcp.TCPTransportClient.seekMessage(TCPTransportClient.java:440)
        ... 3 more
Caused by: org.jdiameter.api.AvpDataException: Not enough data in buffer!
        at org.jdiameter.client.impl.parser.ElementParser.decodeAvpSet(ElementParser.java:319)
        at org.jdiameter.client.impl.parser.MessageParser.createMessage(MessageParser.java:116)
        ... 6 more

And also a BufferOverflow in the end:

        2015-08-14 13:47:23,835 ERROR [org.jdiameter.client.impl.transport.tcp.TCPTransportClient] (TCPReader-1) Buffer overflow occured
java.nio.BufferOverflowException
        at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:183)
        at java.nio.ByteBuffer.put(ByteBuffer.java:832)
        at org.jdiameter.client.impl.transport.tcp.TCPTransportClient.append(TCPTransportClient.java:385)
        at org.jdiameter.client.impl.transport.tcp.TCPTransportClient.run(TCPTransportClient.java:213)
        at java.lang.Thread.run(Thread.java:745)

Problem - encoded/decoded Diameter packets get corrupted (missing child AVPs).

Reason - This is due to the fact that the function getGrouped that converts AvpImpl.java rawData to groupedData is called concurrently when doing encodeAvpSet(). If this is done in the loop before data.write(raw) operation in encodeAvpSet, then all child AVPs could be left unencoded (not written) to the packet (since avp.getRaw().length becomes 0). And since a correct AVP length is written here, the packet gets corrupted.

2.We also obtained a NullpointerException in SessionImpl.java, when doing a release, due to the fact that container concurrently was set to null via setContainer, so this was also fixed. However, don't know what the "// FIXME" is for, but I guess it relates to the same problem.

With the #2 pull I propose a possible fix for this issue. Also to encapsulate more the existing data in AvpImpl.java, i.e. make rawData/groupedData not accessible from outside. ALSO to forbid to swap between rawData/groupedData in runtime, i.e. to not change created AVP.