jdiameter

Hi all,Just got back from FOSDEM 2011 located in Brussels which is one, if not THE biggest open source event in Europe. It's the first time I went there and I was really impressed and had a really great time !Fosdem 2011 had 201 hours of ... [More] presentations, squeezed in 2days (~20 physical hours), that's at least 10 parallel tracks for over 300 speakers IIRCI finally met with, after around 8 years of knowing him virtually, Emil Ivov the project founder and leader of Sip Communicator (soon to be Jitsi) and it didn't really felt like we met for the first time which is a strange feeling, it was more like meeting a good old friend after a long time :-) Thanks for the invitation to your team meeting and for the awesome belgium beers, Emil !It as a blast to meet in flesh and blood with old and new Mobicents users such as Crocodile RCS which is always great to see the innovative ways on how Mobicents is being used or is going to be used. I had a lot of private interesting talks with some other private companies I can't mention publicly here but looking forward to our common future ;-)I also had the chance to meet some of the great leaders behind other open source projects that were eager to learn more about Mobicents as well like Daniel-Constantin Mierla, Co-Founder and Core Developer at Kamailio ( formerly OpenSER) and Russell Bryant, Engineering Manager at Digium, Inc who managed to conduct a great Open Source Telephony track which was full pretty much all day (see the schedule) where I presented Mobicents 2.0, The Java Open Source Communications Platform (click on the link for the slides)So Thanks to all for a great and fruitful event !Jean [Less]

IntroductionA couple of months ago, the Mobicents Diameter Team decided to start a series of educational posts regarding Diameter development using Mobicents Diameter solution.Bartosz Baranowski has kicked-off with the "Creating a "Hello World" ... [More] Application with Mobicents Diameter" article where two things were addressed:Explaining some basics of the Diameter protocol such as Diameter Nodes, Realms, Applications, Messages, AVPs, Sessions and all those fundamental concepts that hopefully helps to make sense out of this;A step-by-step example on how to create server and client instances for a Diameter Application (a fictitious Application was used to exemplify) using Mobicents Diameter. It includes detailed code explanation and it's a good read as a preparation for this one if you're new on the subject.In this second post, we will learn how easy it is to create an Offline Charging Application using Mobicents Diameter. Also, for those not familiar with what is Offline Charging (and Online Charging as well) a brief introduction will be provided.Fasten your seatbelt, the ride is about to begin!Offline and Online Charging. What's that about?Online Charging is the name used by 3GPP for pre-paid charging in the IMS scope. It is the charging which occurs in real-time, where the service cost is deducted from the user balance (which has been previously loaded by the user) while the service is going on. In IMS this is the Ro interface, and is defined by 3GPP TS 32.299 (and extending RFC 4006 - Diameter Credit Control Application).On the other hand, Offline Charging is the 3GPP name for post-paid charging, where the provided services are not paid at the time of their usage but rather in a periodic manner, such as at the end of each month. However, while the service is on course, it's usage is logged as a Call Detail Record (CDR) that will be processed later by a Billing system. This corresponds to the IMS interface Rf, defined also by 3GPP TS 32.299 (inheriting from Diameter Base Accounting in RFC 3588).The CDR generation is the responsibility of an Offline Charging Server.Please keep in mind that while we are using the Online/Offline terminology introduced by 3GPP for IMS, this post does not intend to focus on IMS details, and so, we will only use the Diameter Base Accounting Application, allowing to simplify the exchanged messages and provide a more straightforward tutorial.The Messages and AVPsThe messages exchanged for offline charging, as defined in RFC 3588 - Section 9.7, are only two: Accounting-Request (ACR) and Accounting-Answer (ACA), with Command-Code 271.While only a pair of Request/Answer is defined, it can be used with different purposes, depending on the value of the Accounting-Record-Type AVP (code 480). This AVP can have the following values:EVENT_RECORD (1) - Defines that this is charging for a one-time event, such as a sent SMS;START_RECORD (2) - In a service with a measurable length (eg: voice call) this value defines that such service has started;INTERIM_RECORD (3) - In a service with the above characteristics, this ACR type provides cumulative accounting information;STOP_RECORD (4) - This is used to inform that a service with measurable length has terminated and to provide cumulative accounting information regarding it.Another meaningful AVP is the Acct-Interim-Interval AVP (code 85) where it is specified the interval at which intermediate records should be produced, by sending ACR messages with Accounting-Record-Type set to INTERIM_RECORD. The absence of it, or a value of 0, means that no intermedite records are needed.An important note is that Base Accounting does not define any service-specific AVPs, as it is not intended to be a usable Application but rather the base for the ones being defined. As such, we will 'abuse' from User-Name AVP, and piggyback the Subscription and Service identifiers into it, in the form " . @mobicents.org".Putting it all together!Assuming you already know how to configure and set up the stack in your Java project (which has been explained by Bartosz on the first post of these educational series), let's start by defining the interface for our Charging Client enabler, to be used by the applications:package org.mobicents.diameter.simulator.client;public interface OfflineChargingClient { // Accounting-Record-Type Values -------------------------------------------- static final int ACCOUNTING_RECORD_TYPE_EVENT = 1; static final int ACCOUNTING_RECORD_TYPE_START = 2; static final int ACCOUNTING_RECORD_TYPE_INTERIM = 3; static final int ACCOUNTING_RECORD_TYPE_STOP = 4; /** * Sends an Accounting-Request with Accounting-Record-Type set to "2" and the * corresponding Subscription-Id and Service-Id AVPs filled accordingly. * * @param subscriptionId the String value to be used for Subscription-Id AVP * @param serviceId the String value to be used for Service-Id AVP * @throws Exception */ public abstract void startOfflineCharging(String subscriptionId, String serviceId) throws Exception; /** * Sends an Accounting-Request with Accounting-Record-Type set to "3" and the * corresponding Subscription-Id and Service-Id AVPs filled accordingly. * * @param subscriptionId the String value to be used for Subscription-Id AVP * @param serviceId the String value to be used for Service-Id AVP * @throws Exception */ public abstract void updateOfflineCharging(String subscriptionId, String serviceId) throws Exception; /** * Sends an Accounting-Request with Accounting-Record-Type set to "4" and the * corresponding Subscription-Id and Service-Id AVPs filled accordingly. * * @param subscriptionId the String value to be used for Subscription-Id AVP * @param serviceId the String value to be used for Service-Id AVP * @throws Exception */ public abstract void terminateOfflineCharging(String subscriptionId, String serviceId) throws Exception; /** * Sends an Accounting-Request with Accounting-Record-Type set to "1" and the * corresponding Subscription-Id and Service-Id AVPs filled accordingly. * * @param subscriptionId the String value to be used for Subscription-Id AVP * @param serviceId the String value to be used for Service-Id AVP * @throws Exception */ public abstract void eventOfflineCharging(String subscriptionId, String serviceId) throws Exception; /** * Sets the listener to receive the callbacks from this charging client. * @param listener an OfflineChargingClientListener implementor to be the listener */ public abstract void setListener(OfflineChargingClientListener listener);}Also, we will need the applications to implement the Listener interface, in order to receive the callbacks from the Offline Charging Enabler. The interface to be implemented is quite simple, with only one method for the callback:package org.mobicents.diameter.simulator.client;/** * Listener interface to be implemented by applications * wanting to have Offline Accounting */public interface OfflineChargingClientListener { /** * Callback method invoked by Offline Charging Client to deliver answers * * @param subscriptionId the String value identifying the user * @param serviceId the String value identifying the service * @param sessionId a String value identifying the accounting session * @param accountingRecordType the type of Accounting Record the answer refers to * @param accountingRecordNumber the Accounting Record number the answer refers to * @param resultCode the Result-Code value obtained from the answer * @param acctInterimInterval the interval in seconds to send updates */ public void offlineChargingAnswerCallback(String subscriptionId, String serviceId, String sessionId, int accountingRecordType, long accountingRecordNumber, long resultCode, long acctInterimInterval); }The implementation for the OfflineChargingClient (not complete, just the basics to understanding) is the following:public class OfflineChargingClientImpl implements OfflineChargingClient, NetworkReqListener, EventListener<Request, Answer>, StateChangeListener<AppSession>, ClientAccSessionListener { // Application Id ----------------------------------------------------------- private static final ApplicationId ACCOUNTING_APPLICATION_ID = ApplicationId.createByAccAppId(0, 3); // Configuration Values ----------------------------------------------------- private static final String SERVER_HOST = "127.0.0.1"; private static String REALM_NAME = "mobicents.org"; private SessionFactory sessionFactory; private AccSessionFactoryImpl accountingSessionFactory; private OfflineChargingClientListener listener; private ConcurrentHashMap<String, ClientAccSession> acctSessions = new ConcurrentHashMap<String, ClientAccSession>(); private ConcurrentHashMap<String, Integer> acctRecNumberMap = new ConcurrentHashMap<String, Integer>(); public OfflineChargingClientImpl() throws Exception { // Initalize Stack ... }At this point we just define some constants, configuration values and variables to be used later. We define two maps to allow us to keep sessions and Accounting-Record-Number values stored in the enabler. This could be moved client-side if desired.We will next define some auxiliary methods to assit in common operations, such as creating Accounting-Requests, retrieving the appropriate Accounting-Record-Number, etc.// Aux Methods -------------------------------------------------------------- /** * Gets an accounting record number for the specified user+service id * @param identifier the user+service identifier * @param isStart indicates if it's an initial record, which should be set to 0 * @return the accounting record number to be used in the AVP */ private int getAccountingRecordNumber(String sessionId, boolean isStart) { // An easy way to produce unique numbers is to set the value to 0 for // records of type EVENT_RECORD and START_RECORD, and set the value to 1 // for the first INTERIM_RECORD, 2 for the second, and so on until the // value for STOP_RECORD is one more than for the last INTERIM_RECORD. int accRecNumber = 0; if(!isStart) { accRecNumber = acctRecNumberMap.get(sessionId); accRecNumber = accRecNumber++; } acctRecNumberMap.put(sessionId, accRecNumber); return accRecNumber; } /** * Creates an Accounting-Request with the specified data. * * @param session the session to be used for creating the request * @param accRecordType the type of Accounting Record (Event, Start, Interim, Stop) * @param username the value to be used in the User-Name AVP * @return an AccountRequest object with the needed AVPs filled * @throws InternalException */ private AccountRequest createAccountingRequest(ClientAccSession session, int accRecordType, int accRecNumber, String username) throws InternalException { AccountRequest acr = new AccountRequestImpl(session, accRecordType, accRecNumber, REALM_NAME, SERVER_HOST); // Let's 'abuse' from User-Name AVP and use it for identifying user@service AvpSet avps = acr.getMessage().getAvps(); avps.addAvp(Avp.USER_NAME, username, false); return acr; } /** * Method for creating and sending an Accounting-Request * * @param identifier the user+service identifier to be used in the User-Name AVP * @param accRecType the type of Accounting Record (Event, Start, Interim, Stop) * @throws Exception */ private void sendAccountingRequest(ClientAccSession session, String identifier, int accRecType, int accRecNumber) throws Exception { // Create Accounting-Request AccountRequest acr = createAccountingRequest(session, accRecType, accRecNumber, identifier); // Send it session.sendAccountRequest(acr); } /** * Aux method for generating a unique identifier from subscription and service ids * @param subscriptionId the subscription id to be used * @param serviceId the service id to be used * @return the generated unique identifier */ private String getIdentifier(String subscriptionId, String serviceId) { return subscriptionId + "." + serviceId + "@" + REALM_NAME; }And finally we can do the real implementation for the Offline Charging Client which, hopefully, became a bit simpler.// Offline Charging Client Implementation ----------------------------------- public void setListener(OfflineChargingClientListener listener) { this.listener = listener; } public void startOfflineCharging(String subscriptionId, String serviceId) throws Exception { // Create new session to send start record ClientAccSession session = (ClientAccSession) accountingSessionFactory. getNewSession(null, ClientAccSession.class, ACCOUNTING_APPLICATION_ID, new Object[]{}); // Store it in the map acctSessions.put(session.getSessionId(), session); // Get the account record number int accRecNumber = getAccountingRecordNumber(session.getSessionId(), true); sendAccountingRequest(session, getIdentifier(subscriptionId, serviceId), ACCOUNTING_RECORD_TYPE_START, accRecNumber); } public void interimOfflineCharging(String subscriptionId, String serviceId, String sessionId) throws Exception { // Fetch existing session to send interim record ClientAccSession session = this.acctSessions.get(sessionId); // Get the account record number int accRecNumber = getAccountingRecordNumber(session.getSessionId(), false); sendAccountingRequest(session, getIdentifier(subscriptionId, serviceId), ACCOUNTING_RECORD_TYPE_INTERIM, accRecNumber); } public void stopOfflineCharging(String subscriptionId, String serviceId, String sessionId) throws Exception { // Fetch existing session (and remove it from map) to send stop record ClientAccSession session = this.acctSessions.remove(sessionId); // Get the account record number (and remove) int accRecNumber = getAccountingRecordNumber(session.getSessionId(), false); this.acctRecNumberMap.remove(session.getSessionId()); sendAccountingRequest(session, getIdentifier(subscriptionId, serviceId), ACCOUNTING_RECORD_TYPE_STOP, accRecNumber); } public void eventOfflineCharging(String subscriptionId, String serviceId) throws Exception { // Create new session to send event record ClientAccSession session = (ClientAccSession) accountingSessionFactory. getNewSession(null, ClientAccSession.class, ACCOUNTING_APPLICATION_ID, new Object[]{}); // No need to store Session or Accounting-Record-Number as it's a one-shot. sendAccountingRequest(session, getIdentifier(subscriptionId, serviceId), ACCOUNTING_RECORD_TYPE_EVENT, 0); } // Client Acc Session Listener Implementation ------------------------------- public void doAccAnswerEvent(ClientAccSession appSession, AccountRequest request, AccountAnswer answer) throws InternalException, IllegalDiameterStateException, RouteException, OverloadException { // Extract interesting AVPs AvpSet acaAvps = answer.getMessage().getAvps(); String subscriptionId = null; String serviceId = null; try { String username = acaAvps.getAvp(Avp.USER_NAME).getUTF8String(); // It's in form subscription.service@REALM_NAME String[] identifiers = username.replaceFirst("@" + REALM_NAME, "").split("\\."); subscriptionId = identifiers[0]; serviceId = identifiers[1]; } catch (Exception e) { e.printStackTrace(); } // Get the session-id value String sessionId = appSession.getSessionId(); // We must be able to get this, it's mandatory int accRecType = -1; try { accRecType = answer.getAccountingRecordType(); } catch (Exception e) { e.printStackTrace(); } // We must be able to get this, it's mandatory long accRecNumber = -1L; try { accRecNumber = answer.getAccountingRecordNumber(); } catch (Exception e) { e.printStackTrace(); } // If we can't get it we'll fallback to DIAMETER_UNABLE_TO_COMPLY (5012) long resultCode = 5012L; try { resultCode = answer.getResultCodeAvp().getUnsigned32(); } catch (AvpDataException e) { e.printStackTrace(); } // Here we fallback to 0, it means the same as omitting long acctInterimInterval = 0; try { acctInterimInterval = acaAvps.getAvp(Avp.ACCT_INTERIM_INTERVAL).getUnsigned32(); } catch (AvpDataException e) { e.printStackTrace(); } // Invoke the callback to deliver the answer listener.offlineChargingAnswerCallback(subscriptionId, serviceId, sessionId, accRecType, accRecNumber, resultCode, acctInterimInterval); } public void doOtherEvent(AppSession appSession, AppRequestEvent request, AppAnswerEvent answer) throws InternalException, IllegalDiameterStateException, RouteException, OverloadException { // We can ignore this }Given the above implementation of what can be seen as the enabler for offline charging, now our Example Application should implement the following state machine using the enabler:So let's get our hands dirty with the example application implementation, which should implement the above specified listener interface:package org.mobicents.diameter.simulator.client;import static org.mobicents.diameter.simulator.client.OfflineChargingClient.*;public class ExampleApplication implements OfflineChargingClientListener { // Internal Client State Machine -------------------------------------------- private static final int STATE_IDLE = 0; private static final int STATE_START_ACR_SENT = 2; private static final int STATE_START_ACA_SUCCESS = 4; private static final int STATE_INTERIM_ACR_SENT = 6; private static final int STATE_INTERIM_ACA_SUCCESS = 8; private static final int STATE_STOP_ACR_SENT = 10; private static final int STATE_STOP_ACA_SUCCESS = 12; private static final int STATE_EVENT_ACR_SENT = 14; private static final int STATE_EVENT_ACA_SUCCESS = 16; private static final int STATE_END = 18; private static final int STATE_ERROR = 99; private int currentState = STATE_IDLE; public static void main(String[] args) throws Exception { ExampleApplication app = new ExampleApplication(new OfflineChargingClientImpl()); app.occ.startOfflineCharging("", ""); } private OfflineChargingClient occ; public ExampleApplication(OfflineChargingClient occ) { this.occ = occ; occ.setListener(this); } public void offlineChargingAnswerCallback(String subscriptionId, String serviceId, String sessionId, int accountingRecordType, long accountingRecordNumber, long resultCode, long acctInterimInterval) { // Handle the EVENT situation if(accountingRecordType == ACCOUNTING_RECORD_TYPE_EVENT) { if(this.currentState == STATE_EVENT_ACR_SENT) { if(resultCode == 2001) { this.currentState = STATE_EVENT_ACA_SUCCESS; System.out.println("(((o))) Event Offline Charging for user '"+ subscriptionId + "' and service '" + serviceId + "' completed! (((o)))"); // and now just to be correct... this.currentState = STATE_END; } } else { this.currentState = STATE_ERROR; throw new RuntimeException("Unexpected message received."); } } // Handle START / INTERIM / STOP situation else { switch(this.currentState) { // Receiving an Answer at any of these states is an error case STATE_IDLE: case STATE_EVENT_ACA_SUCCESS: case STATE_START_ACA_SUCCESS: case STATE_INTERIM_ACA_SUCCESS: case STATE_STOP_ACA_SUCCESS: // At any of these states we don't expect to receive an ACA, move to error. this.currentState = STATE_ERROR; break; // We've sent ACR EVENT case STATE_START_ACR_SENT: if(accountingRecordType == ACCOUNTING_RECORD_TYPE_START) { if(resultCode >= 2000 && resultCode < 3000) { // Our event charging has completed successfully. We're done! System.err.println("(((o))) Offline Charging for user '" + subscriptionId + "' and service '" + serviceId + "' started... (((o)))"); if(acctInterimInterval > 0) { try { // Let's sleep until next interim update... Thread.sleep(acctInterimInterval * 1000); // We send an update at the correct time occ.interimOfflineCharging(subscriptionId, serviceId, sessionId); } catch (Exception e) { this.currentState = STATE_ERROR; throw new RuntimeException("Unable to schedule/send interim update.", e); } } } else { // It failed System.err.println("(((x))) Offline Charging for user '" + subscriptionId + "' and service '" + serviceId + "' failed with Result-Code="+ resultCode + "! (((x)))"); } } else { this.currentState = STATE_ERROR; throw new RuntimeException("Unexpected message received."); } break; // We've sent ACR START case STATE_INTERIM_ACR_SENT: if(accountingRecordType == ACCOUNTING_RECORD_TYPE_INTERIM) { if(resultCode >= 2000 && resultCode < 3000) { // Our offline charging has started successfully... System.out.println("(((o))) Offline Charging for user '" + subscriptionId + "' and service '" + serviceId + "' updated... (((o)))"); if(acctInterimInterval > 0) { try { // Let's sleep until next interim update... Thread.sleep(acctInterimInterval); // We send an update at the correct time occ.interimOfflineCharging(subscriptionId, serviceId, sessionId); } catch (Exception e) { this.currentState = STATE_ERROR; throw new RuntimeException("Unable to schedule/send interim update.", e); } } } else { // It failed, let's warn the application System.out.println("(((x))) Offline Charging for user '" + subscriptionId + "' and service '" + serviceId + "' failed to start with Result-Code=" + resultCode + "! (((x)))"); } } else { this.currentState = STATE_ERROR; throw new RuntimeException("Unexpected message received."); } break; case STATE_STOP_ACR_SENT: if(accountingRecordType == ACCOUNTING_RECORD_TYPE_INTERIM) { if(resultCode >= 2000 && resultCode < 3000) { // Our offline charging has started successfully... System.out.println("(((o))) Offline Charging for user '" + subscriptionId + "' and service '" + serviceId + "' stopped! (((o)))"); } else { // It failed, let's warn the application System.out.println("(((x))) Offline Charging for user '" + subscriptionId + "' and service '" + serviceId + "' failed to stop with Result-Code=" + resultCode + "! (((x)))"); } } else { this.currentState = STATE_ERROR; throw new RuntimeException("Unexpected message received."); } break; default: this.currentState = STATE_ERROR; throw new RuntimeException("Unexpected message received."); } } }}As it can be seen it turns to be really simple to implement such Application using Offline Charging in this way. The above application also provides an enhancement, which is to automatically wait and send the interim ACR updates (lines 73-85 and 107-119). That obviously is a design choice, which can be changed if control over that behavior is intended.ConclusionAs this article was meant to demonstrate it's simple to add Offline Accounting to your applications using Mobicents Diameter solution. Several options (and scenarios) were simplified in order to keep the example easier to understand and follow the steps, as well as to give a better understanding of the Mobicents Diameter solution, while still rendering a completely functional solution.You can learn more about Mobicents Diameter at http://www.mobicents.org/diameter/. [Less]

At the end of last century when VoIP just did its first steps into the world, engineers hit on the problem that classic methods gave too optimistic performance results. The system designed and tested in lab at heavy load failed at low and mid load in ... [More] real network. This phenomenon caused deep research and recent studies have shown the presence of long-range dependence or even fractals (or self-similarity) in teletraffic wich can not be described by traditional Markov's model such as Poisson process.But what is the fractal and self-simality and why it kills servers? The mathematics behind the fractals began in 17th century with researches of recursive self-similarity by Weierstrass and finally in 1975 Mandelbrot used the word fractal to identify objects whose Hausdorff dimension is greater then its topological dimension. Instead of digging into the complicated details of the theory let's consider the example - snowflake. Snowflakes are amazing creations of nature. They seem to have intricate detail no matter how closely you look at them. One way to model a snowflake is to use a fractal which is any mathematical object showing "self-similarity" at all levels known as Koch snowflake.The Koch snowflake is constructed as follows. Start with a line segment. Divide it into 3 equal parts. Erase the middle part and substitute it by the top part of an equilateral triangle. Now, repeat this procedure for each of the 4 segments of this second stage. See Figure 1. If you continue repeating this procedure, the curve will never self-intersect, and in the limit you get a shape known as the Koch snowflake.Amazingly, the Koch snowflake is a curve of infinite length! And, if you start with an equilateral triangle and do this procedure to each side, you will get a snowflake, which has finite area, though infinite boundary!Let's leave the question why self-simlarity appears without answer at this moment because it is not simple question and try to understand why fractals are so dangerous for telco applications using the dry theory. So what we know is that the distribution differs from normal and it varies. Now let's imagine that at some point system meets with "problem" where problem is caused by unsuccessful combination of many parameters (number of messages arrived, the time distance between them, unexpected logical relation between messages, etc). Self-similarity means that this problem will be occured infinite number of times just with different scales. So if problem can happen only once it will return again and again and again... It explains why performance in lab always greater the real one, and mistake can be like 100 times or even infinity.Of cource would be inerested to understand the physics of this process. Why self similarity appears? This questions bothers many peoples and since the pioneering work on self-similarity of network traffic by Leland, many studies have attempted to determine the cause of this phenomenon. Initial efforts focused on application factors. For example, Crovella and Bestavros investigated the cause of self-similarity by focusing on the variability in the size of the documents transferred and the inter-request time. They proposed that the heavy-tailed distribution of file size and “user think time” might potentially be the cause of self-similarity found in Web traffic.Alternatively, a few studies have considered the possibility that underlying network protocols such as TCP could cause or exacerbate the phenomenon. In particular, Peha first showed that simple ARQ mechanisms could cause the appearance of self-similarity in congestible networks, but he did not examine the ARQ mechanism in TCP. Veres later showed that TCP could sometimes create self-similarity in an individual TCP stream. Interestingly, in some circumstances, aggregate traffic through bottleneck tends toward Poisson while individual streams remain self-similar, presumably because congestion control mechanisms tend to keep the aggregate throughput close to the capacity whenever load exceeds the capacity. However, the work was based on the assumption that load is infinite (heavy load), which is obviously not sustainable in real networks.In particular, when load is low and loss is rare, traffic looks Poisson. When load is high and the network is overloaded, TCP congestion control can smooth out the burstiness of the aggregate stream so that traffic at the bottleneck tends to Poisson. However, when load is intermediate and the network is prone to occasional bouts of congestion, as is typical of many networks, traffic can become self-similar. Moreover, factors such as round trip time and number of streams passing through the bottleneck can cause the network to become congested at different loads, and consequently affect the range of load over which self-similarity can be observed.The high level signalling protocols are also affected by self-similarity (this is the same "packet" switched traffic just in bigger scale). Circuit switched telephony was looking more or less stable in this zoo till resent studies detected self-simaliry in global SS7 network where again signalling messages transmitted over data links becomes packets in packet switched network.Resuming everything said above would be nice to add that "self-similarity" can be measured. The theory defines Hurst parameter wich varies in range [0-1]. The value H = 0,5 relates to pure Markov's source, H less then 0,5 means that process is not self-similar and H greater then 0.5 indicates that process has self-silmilar behaivor. [Less]

Media Server is the systems in which the operational correctness depends not only on the results of the computation but also on the time at which these results are produced. Time critical processes must be executed under timeliness limitation, which ... [More] is usually described as a term deadline. Tasks must either be completed or its execution must start by the deadline. The scheduler is the component of the Media Server that selects which process to run next. The scheduler (or process scheduler, as it is sometimes called) can be viewed as the code that divides the finite resource of processor time between the runnable processes on a server.Many papers have been published in the field of real-time scheduling. Unfortunately much of the published work consists of scheduling algorithms that are defined for systems with preemptive multitasking like Real Time Operating Systems. In preemptive multitasking, the scheduler decides when a process is to cease running and a new process is to resume running. The act of involuntarily suspending a running process is called preemption. The time a process runs before it is preempted is predetermined, and is called the timeslice of the process. Primitive thread management capabilities of standard Java are making unavailable direct implementation of known algorithms. However it is possible to extract from this published material some general purpose techniques.Thread model and task queue.There is no way to distrubute CPU time between threads using the Standard Java API. Normaly it means that we anyway can use published materials but with assumption that number of CPUs equal to 1 and construct scheduler around uniprocessor model. Let's now consider CPUs as a single processor with total power equal to sum of all available CPUs. If all CPUs are equivalent, what we have exactly, then it allows to use the model with dynamic task priorities and EDF policy as base. The following diagram depicts the architecture of scheduler.Each time when new task arrives Acceptor analysis parameters of the task, determines its priority and delivers task to the "ready queue" where position of the task relates to its priority. The task with high priority resides closer to the head of queue and task with lower priority resides closer to tail.CPUs executes tasks and calculate feedback as difference between estimates and actual result. Finally Scheduler updates the miss rate counter used for congestion control and updates task priority. I/O CPU Burst CycleSaying about media server it is possible to classify inner processes as "IO bound" or "CPU bound". The server make heavy use of I/O endpoints and spend much time waiting for I/O operations to complete; the latter are number-crunching transcoding tasks that require a lot of CPU time. The execution of a process consists of an alternation of CPU bursts and I/O bursts.The frequency of I/O operations usage inside Media server is very high, espacially for legacy DS0 channels, what means that I/O actions must fill the whole space between CPU bound tasks.Test resultsThe actual implementation is still under strong test but even the first tests shows high stability and very good CPU utilization. Bellow is the diagram of average miss rate as dependency of scheduled periodic tasks with period - 20ms, worst execution time 1ms and max jitter 3ms. Congestion control disabledThe archived miss rate is comparebale with bestes real time schedulers constructed on preemtive OS. This test was running on 4-core CPU and thus 80 tasks scheduled relates to 100% of CPU utilzation. Very good result compared with RMA theoretical maxim of 69,3%, [Less]

We are happy to announce release of Mobicents SS7 1.0.0.BETA6-----------------------------------------------Release includes:-----------------------------------------------ASN library ss7 protocols including the lowest layer MTP2/MTP3 to higher layer ... [More] ISUP, SCCP, TCAP and MAP The most notable changes in this release are as follows: Management : Creating and managing Linkset's can be done by Mobicents SS7 CLI Linkset Implementation : Specific Linkset exist for specific hardware. The linkset management module can set-up linkset specific to hardware configured on your server small bug fixes and enchancements For details on stack creation and configuration please refer to docs available online http://www.mobicents.org/ss7/docs.htmlThe examples are not part of release. Please refer to JSLEE 2.1+ GA or subsequent MSS release.Note that this release is a BETA. Modules are under development and some parts MAY change.Let us know if you have any issues.Where to download from? https://sourceforge.net/projects/mobicents/files/Mobicents%20Protocols%20Suite/------------------Release Contents------------------ * ASN v1.0.0.BETA3 * SS7 v1.0.0.BETA6------------------SVN Trunk Checkout------------------http://mobicents.googlecode.com/svn/trunk/protocols/asnhttp://mobicents.googlecode.com/svn/trunk/protocols/ss7------------------SVN Trunk Browse------------------http://code.google.com/p/mobicents/source/browse/#svn%2Ftrunk%2Fprotocols%2Fss7http://code.google.com/p/mobicents/source/browse/#svn%2Ftrunk%2Fprotocols%2Fasn------------------SVN Tag Checkout------------------http://code.google.com/p/mobicents/source/browse/#svn%2Ftags%2Fprotocols%2Fasn%2Fasn-1.0.0.BETA3http://code.google.com/p/mobicents/source/browse/#svn%2Ftags%2Fprotocols%2Fss7%2Fmobicents-ss7-1.0.0.BETA6----------------How to Use it?---------------- Please refer to online documentation.------------------More Information------------------ For more detailed information, please visit the following sites: * Mobicents Google Group, for posting questions ( http://groups.google.com/group/mobicents-public) * Mobicents Homepage (http://www.mobicents.org)Mobicents SS7 Team [Less]

Hello there, Mobicents JAIN SLEE 2.3.0.FINAL, codenamed SUPERSONIC, is now available for download, so what are you waiting for? Get all the details about the release, including the download link, at http://goo.gl/e3vMF

The first time I heard about RCS, this year, when a company asked if Mobicents SIP Presence Service (MSPS) was compliant, I was curious about what it was, but I promised myself, after 6 months struggling without a MSPS release, we would not dive into ... [More] another layer of over complicated specs, no way we would consider one more possible dead end. In short, we ignored it… till another company asked about the same thing, and another one, and it kept going… In the end of last summer we were involved in a big RCS network plan, and it was perfectly clear to me, the SIP Presence industry was asking for RCS, and RCS only. So I went through an evaluation of what was RCS about, to finally decide if MSPS should embrace it.RCS stands for Rich Communication Suite, and it is a suite of IP telco standards, which works out other standards. Confusing, the least… RCS is done by the GSMA workgroup, and does not defines any new technology… What? This is getting weird!  My first thoughts, also the fact that it was done in IMS fashion, through numbered "Release"s, made me fear the worst, after all the GSMA members possibly overlap with 3GPP and OMA, chances it could be the same people, using same methodologies, drawing the RCS specs.So I spent some time reading the specs and let me tell you, one must praise GSMA work, quite simply, RCS takes on IMS and OMA specs, rearrange them, simplify as much as possible, so it can be applied to today's networks and services, as fast as possible, an using agile methodologies! Sounds great, sign me in!Wait a minute, I know, some would say it is all wrong, we should instead had first the basic layer, the RCS simplicity, and only then we should have it extended to provide the zillion features IMS has, and which nobody cares or needs. Not a surprise, I fully agree with such view. Also some say it is too late, that the consumer already decided for services which are not provided by operators, maybe not, hopefully not, in my humble opinion, RCS may be the very last chance, at least for SIP Presence.Let me try to give you an insight of what we are talking about, RCS has 3 releases, each upgrades the previous one. I will focus on SIP Presence only, but RCS touches more than SIP Presence, it also works other services such as IM.RCS Release 1 evolves around the concept of the Enhanced Address Book (EAB), an evolution of the usual address book. In short the address book is decorated with enriched information, coming from different services. This plays nicely with today's wishes for cloud stored information, unified social networks status updates, contact content such as portrait icons. I'm not going into technical details, but I for sure am someone who is aware of the design issues around SIP Presence, its hard time scaling due to huge traffic, the dozens of ugly workarounds to make it work, and RCS is a nice step forward into the right direction, there are simple decisions that deeply simplify the network design, making it more like "old" presence networks, which simply work. One remark, it takes quite an effort to define this endorsing IMS and OMA, 27 pages of functional description, plus 39 of technical realization, it should be a lesson for everyone in these standard bodies when defining more extensions or new versions.The RCS Release 2 effort focuses on enabling access to rich communication services from a wider range of devices. In short it tells that the user has multiple devices, for instance a mobile phone and a PC, possibly concurring for services, and adapts Release 1 for that. It also introduces the Network Address Book, which is just the realization that the EAB needs to be in the network and sync the multiple user devices.The RCS Release 3 mostly consolidates Release 2 features, and adds some minor enhancements, such as preparing the network for different usages of it, for instance users with devices, which are not connected to mobile network, instead only have broadband connections. In my humble opinion a very important and positive decision, it's about time to consider these scenarios and find out new opportunities. It is weird to say this, but the fact that the industry finally acknowledges that content sharing between two users may happen off the voice/video session is a victory, welcome to the world not session centric. Can you imagine what would be the outcome if we have specs that release the session protocols from all these extra services almost nobody uses, how much simpler, cheaper and efficient the session networks, services and clients would be?As I said, RCS is a big step in the right direction, a revolution without new technology. For MSPS you can expect to target RCS compliancy as soon as possible, as a matter of fact the developing tasks for such work area already in the Issue Tracker, with a total estimation of about 200h of work, at this point we just need to understand what 3rd parties are interested to collaborate, to come up with a release date, Mobicents does not have the resources to walk this path alone, or perhaps I should say, not before it may be too late. Please get in touch with me if you are interested in contributing. We know that RCS needs Mobicents too, an open source implementation with a strong community behind it.Stay tuned.References and Additional Resources: • RCS Homepage • RCS Release Documents • RCS Market Survey [Less]

That's right, only one week after Mobicents Sip Servlets 2.0.0.ALPHA1 has been released, here comes Mobicents Sip Servlets 1.5.0.FINAL, certified against the Sip Servlets 1.1 specification and working on top of Tomcat 6.0.29 and JBoss AS 5.1.0.GA ... [More] .And because we don't want Santa Claus to loose any important calls, we crafted you a release focusing on High Availability improvements :Early Dialog FailoverLong Lived SIP Calls PassivationN nodes clusters (domains) linear scalabilityLoad Balancer support for Early Dialog FailoverThe other highlights of this release are :Move to Mobicents Media Server 2.1.0.BETA1 with enhanced qualityMove To Mobicents Diameter 1.3.3 with enhanced performance and Gx support50 bug fixesSpecial Thanks to the community and customers for their contributions to this release, especially to :Naoki Nishihara from OKI who reported Issue 2216 and contributed a fix for itHoraci Macias from Avaya who reported Issue 2115 and contributed a fix for itCheck the complete Roadmap to see what's cooking aheadDownloads are here, online documentation is here, User Guide is here, the 1.5.0.FINAL changelog and roadmap is here and the Mobicents Google Groups for feedback and questions is here.Try out this new awesome release and give us your feedback !Enjoy and Have Fun !The Mobicents Sip Servlets Team [Less]