SS7 weekly chat - 7th March 2012

[Amit Bhayani]

Summary

1) The USSD GW is moved to its own home now. Here is the link http://code.google.com/p/ussdgateway/

2) USSD GW has too many pieces for configuration. We are deciding on what is best way to have UI that can give unified look and feel for admin. For example configuring SS7, USSD specific message, Reporting etc

3) 1.0.0.CR4 is delayed due to addition of new tasks at last moment. Release Date postponed by couple of weeks.

Chat

10:33 AM Sergey has joined

  Bartosz has joined

 me: Hi Guys

  lets have our weekly conf chat

10:34 AM lets start with
1) USSD GW
2) 1.0.0.CR4
3) 2.0.0.BETA1

  for 1) I sent mail few days ag

  ago

  1) OnDialogRequest may come with Origref and DestRef (think of Ericsson MAP). ParentSbb should be storing this and while forming xml payload it should add MSISDN from here if process_unstructured_request doesn't include it
2) the XML payload structure needs to change. We need to add some flag distinguishing Unstructured SS request from Notify.
3) Edge condition : No rule defined. GW should abort MAP Dialog or best send back some error response. The error response should be configurable
4) Edge condition : Rule failed. same as 3) above
5) Edge condition : HTTP Server not available for processing request.
6) Edge condition : HTTP Server taking too long, Map Component Invoke timeout occurs
7) Complete all TODO's in HttpClientSbb and ParentSbb
8) Load test for USSD GW
9) Functionality Test for USSD GW

  1) and 2) is already committed

10:35 AM Sergey the repository is here http://code.google.com/p/ussdgateway/

  also in MAP Service Messages I am thinking to expose the OperationCode

10:36 AM for example in USSDMessage.jaba

  USSDMessage.java

  have
public int getOperationCode();

10:37 AM which returns the operation code for this message

  but we have two forms of message "Request" and "Response"

  while Request will have same OperationCode as in GSM spec

10:38 AM for response we will append 0x80 at beginning so as to distinguish response from request

  for example

  ProcessUnstructuredSSResponseIndication == 0x0000003B //59

10:39 AM sorry

  ProcessUnstructuredSSResponseIndication == 0x8000003B //59

  and

  ProcessUnstructuredSSRequestIndication == 0x0000003B //59

  wdyt guys?

10:40 AM Sergey: "USSDMessage.java" - is this from MAP project?

10:41 AM me: yes

  public interface MAPMessage {

public long getInvokeId();

public void setInvokeId(long invokeId);

public int getOperationCode();

public MAPDialog getMAPDialog();

public void setMAPDialog(MAPDialog mapDialog);



}

 Bartosz: add x80 where, why ?

10:42 AM me: Bartosz this is to distinguish between various MAP messages

  and also to distinguish response from request

10:43 AM Sergey: May be a better approach is an extra method like "isResponse()" ?

 Bartosz: distinguish where?

10:44 AM Sergey: in MAPMessage

 me: Sergey, but it should also be able to identify which message this

  not only if its response or request

  Bartek, think at Application level

  we have onProcessUnstructuredReq() onProcessUnstructredResp() etc

  so far so good

10:45 AM but now these messages are used in application

  and they have use MAPMessage interface

  so how will they know which message they are working with?

  unless they do if(xxx instance of ProcessUnstructuredReqInd){ ... } else { ...}

10:46 AM Sergey: "not only if its response or request" - what may be else?

 me: Sergey like to distinguish is MAPMessage is processUnstructuredReq or UnstructuredRequest or UnstructuredNotify or MoForwardMessage

  etc

 Bartosz: well, thats a valid way to do that in java OO :d

10:47 AM or have something like

 me: it is Bartek but very in-convenient

 Bartosz: getMessageType()

 me: Bartek Operation-Code is as per specification

  every MAP message has unique Operation COde

  AFAIK

10:48 AM Sergey: "processUnstructuredReq or UnstructuredRequest" - they have different application codes

 Bartosz: well, still you will have to decalre static ints to match those values, wont you ?

10:49 AM Sergey: sorry "operation codes"

 me: Bartek its already decalred

10:50 AM Sergey: I prefer instead of "public int getOperationCode();"

  something like "enum MapMessageType"

 me: look at MAPOperationCode.java

 Sergey: public MapMessageType getMessageType();

10:51 AM We will be able to have several MapMessageType's for each case

 me: Hmm, Sergey you mean same MAP Message but different version ?

10:52 AM Sergey: But we can introduce "public int getOperationCode();" also

  "different version", request/response, special propriarityes style like Ericsson

10:53 AM me: >>propriarityes style

 Sergey: enum is better then "decalre static ints to match those values"

 me: yes makes sense, this is case where OperationCode might be same but "enum MapMessageType" are different

10:54 AM Sergey: "this is case where OperationCode might be same but "enum MapMessageType" are different" - yes

 me: Ok I will open a issue for this

  Sergey can you take up this please?

10:55 AM Sergey: ok, I can

 me: k

  Guys sorry, lets break here

  have a call in 5 mins

13 minutes

11:08 AM Sergey: One more remark: if we refactor MAPMessage:

11:10 AM add "void MAPDialogListener.onMAPMessage(MAPMessage msg);"

11:11 AM This evenv will be invoked before invoking events like "onProcessUnstructuredSSRequestIndication()" so MAP user can get all recieved message list just by processing one event

30 minutes

11:42 AM me: back

  >>add "void MAPDialogListener.onMAPMessage(MAPMessage msg);"

  >>Sergey: This evenv will be invoked before invoking events like "onProcessUnstructuredSSRequestIndication()" so MAP user can get all recieved message list just by processing one event

  I am not sure we want two events to be fired

  rather

11:43 AM we should avoid firing twice

 Sergey: may be

11:44 AM But this method may help for example for trace-parcer

 me: may be a configurable parameter at MAPStack level

  to enable this or disable this?

  as in production I can definitely see its not needed

11:46 AM Sergey: I do not propose a configurable parameter

  If tou do not use it, just not to process onMAPMessage()...

11:47 AM But yes, this is mostly for degugging, searching a traffic, ....

5 minutes

11:52 AM me: so what is the consensus do we have this "onMAPMessage()" or not?

11:53 AM Sergey: do not know, I prefer the presence of this, but I am not sure

11:54 AM me: Ok lets not have it now. In future if we feel need we can add it

 Sergey: We can add "enum CapMessageType" also (int a CAP)

11:55 AM me: yes makes sense

 Sergey: into a CAP

 me: Ok. Lets start discussion USSD GW in sometime .. have to run for another stuff again :(

11:56 AM sorry for not sticking to chat

11:57 AM Bartosz: lol

11:59 AM me: Bartek quick question, the JCC example that we tested long back with operator, did we have some kind of simulator to test it offline?

12:02 PM Bartosz: no

  it was tested against live core SS7 netowrk

59 minutes

1:02 PM Sergey: sorry guys, I should run home, will online later

9 minutes

1:12 PM me: back

19 minu

4:08 PM Sergey has joined

  Bartosz has joined

 Bartosz: ?

  3rd?

4:09 PM Sergey: Hello!

  Will we continue?

4:14 PM me: USSD GW

4:17 PM Bartosz: sooo :) ?

  ping?

 me: ok Bartek you have more or less requirements

  One important thing is consistent UI for O & M

4:18 PM like setting up the SS7 + Monitoring of USSD GW

  also keep in mind that GW can work in active + active mode

4:19 PM Bartosz: active + active ?

 me: yes like 2 instances

  and we want a way where same UI can handle both

  this UI may be installed in any one instance

  or totally independent 3rd instance

4:20 PM for SS7 config we can make UI talk to SheelExecutor by using the same TCP socket

 Bartosz: wait wait, so Im supposed to create GUI :P ?

4:21 PM me: we are identifying the tasks

  not assigning :P

  UI is completely independent

  but we need to expose the stats and config in consistent way

  so UI can be connected to core seamlessly

 Bartosz: so it should be a bit different :P

  Goals for UI:

4:22 PM 1. unified access

  2. configure

  - sccp

  - m3ua

  - rules

  - conf params of USSD GW

  something like that :P

 me: right

  like config message if short code not configured

4:23 PM config message if short code points to URL which is not available

  config message if some server side error

  these messages are sent back to user

  also the JSLEE UsageParameter's exposed vi this UI

4:24 PM parameters like current number of active dialogs for any short code

  GW up time

  etc

4:25 PM and once we generate the CDR and persist in DB

  same UI can generate reports too

  now the problem is

  SS7 config is via CLI

4:26 PM JSLEE config like MAP SSN number is via resource-adaptor.xml file

  I am not sure where the config message should go? In DB? Flat file?

4:27 PM wdyt?

 Bartosz: hmm I wonder if SLEE will get idea of @Inject :P

4:29 PM well if we intend to have sinle place to store that DB will be best place

  or maybe profiles

 me: profiles can be modified at runtime

  right?

4:31 PM Bartosz: y

 me: hmm

 Bartosz: and services can store messages localy

  and once modified, profiles will send "update event"

4:32 PM me: but this update event will be consumed by only one SBB Entity

4:34 PM Bartosz: no, by all entities

  well, maybe thats not a best practice, possibly messages should change only for new instances of SBB Entities

4:35 PM me: yeah

  I guess UI will call JMX Operation to change the Profile Value

  and new SBB Entities will have this latest value

4:36 PM Bartosz: for that we dont need profile, but thats the easiest way in SLEE

4:38 PM me: May be write a simple MBean that pushes the changes in DB

  when edited

  and also keep local reference

  and reads from DB when service started ?

  in this case these static data is in memory

4:39 PM and SBB's just refers from local MBean server?

 Bartosz: thats a detail :)

  dont think MBean is a good way to access DB

  there is a lot of 3rd party tools that can do that, lets not add more tasks

 me: Ok

4:40 PM but the point is unified UI :)

  don't want users to jump between jmx-console, slee-management-console, admin-console and ussd-console :)

  so all our work should keep these points in mind

4:42 PM for SSN number that we specify in resource-adaptor.jsr

  resource-adaptor.jar

  what is best way to expose via UI?

 Bartosz: there is already JMX OP that can do it

  updateCOnfig

4:43 PM it has to be implemented in RA though, but thats few lines

 me: right

  so before RA is activated we give option via unified UI to update the SSN number

4:44 PM is the change persisted bartek ?

  like if system restarts

  will it take configured value?

 Bartosz: no

4:45 PM me: oouch

  this will not work for us

  SS7 persists all config

  so if system reboots

  it brings itself back to same value

  same state*

4:46 PM I sometimes feel to ditch SLEE all together and just create a layer using MAP :P

  we will be able to control it at all levels

4:47 PM do you think its good move to ditch SLEE ?

  and have standalone USSD like Media Server

4:48 PM Bartosz: brings a bit more effort

  but makes testing with junit available

  but makes us responsible for threads, sync, instances etc

 me: I think it keeps everything very clean

4:49 PM yes agree that effort is bit more

  but on longer run it will be very neat and clean

4:50 PM Bartosz: cant be sure of that :)

4:51 PM me: I am also thinking to ditch JBoss Rules

  :)

  for USSD GW we will have very simple rules

4:52 PM like if dialed *xxxx# do this

  which can be simple HashMap

4:55 PM Sergey has joined

4:56 PM Sergey: ping

 me: Bartek do you think we should think over this?

  or we decide SLEE as final

  ?

  pog

  pong

4:57 PM Bartek?

4:58 PM Bartosz: sorry, I dont get pings :/

  I would be very careful here

4:59 PM me: agree

5:00 PM so what is your vote?

 Bartosz: I would stay with SLEE atleast for now

5:01 PM if its bad in any way, we can move next version to standalone

  but thats IMHO a step back

 me: what you mean by step back?

5:02 PM Bartosz: to java 1 :P

 me: yes understood, but by step back you mean we are not eating our own dog food - SLEE?

  or you mean we are doing lot more work and not gaining any advantage over SLEE ?

 Bartosz: later

5:03 PM me: hmm

  consider simple example that pure SS7 stack achieved 15000 MAP messages/sec

  now I see bottle neck would be 1) Database 2) Slee

5:05 PM Sergey: Is SLEE really a bottle neck (this is just a question)?

5:06 PM me: Sergey we don't know as of now

  probably its not

  but I am afraid that we are touching too many things beyond our control

  like JBoss AS, SLEE

5:07 PM + we don't single way of Operations & Management

  JBoss comes with tons of things

  90% of those are not useful for us

 Bartosz: we can remove those lol

 me: right Bartek we can

5:09 PM ok lets leave this topic here now

  but keep in mind about unified UI and same UI may be controlling multiple USSD GW Instances in production

5:10 PM Sergey: Amit, sorry, will CLI interface for SCCP for example be supported at SS7?

5 minutes

5:15 PM me: yes Sergey

  it is already supported now

24 minutes

5:40 PM 

I think it makes sense to expose SS7 config also via JMX

  and our external UI just connects over JMX

  wdyt?

6:16 PM Sergey: "our external UI" - do you mean CLI inerface now

 me: nope Sergey

  the Web GUI

  to allow users to control SS7 over nice web interface

6:17 PM but I think even CLI can leverage the JMX

  and we can completely remove custom TCP layer that we have now

6:18 PM Sergey: "nice web interface" - this is not yet implementd, yes?

 me: not yet

  we are discussing UI for not only SS7 but also USSD

6:19 PM Bartosz: twiddle uses jmx

  one for SLEE

6:20 PM me: yeah we can think about having something similar

 Sergey: does JMX has a GUI / web interface or it is just a "gate" and GUI/web is teh separate task?

6:21 PM Bartosz: standard manageement interface for apps

  no GUI by default though jboss 5 came with simple console

 me: GUI is separate task, but there are JMX Managers like jConsole which can connect with remote MBeanServer and expose all MBeans via UI

10 minutes

6:31 PM Sergey: SCCP oam needs to be updated now

6:32 PM Will we do it in CLI this step?

19 minutes

6:51 PM me: yes I think for now you can leave CLI

6:52 PM but I hope the hooks are present in SCCP management for O and M

6:55 PM brb

[imranrazakhan]

Hi All,

Standalone USSD GW would be a good idea like Standalone MMS. Community which is only interested in USSD GW will be more focused on it and test and develop application without learning SLEE.

Its good to have things which are not tightly coupled.

Regards,

imran

[Ivelin Ivanov]

Imran,

Thank you for the feedback. The new project was created in recognition of the demand for a standalone USSD GW product that can be easily administered (GUI, CLI, JMX, SNMP) and interfaced by enterprise and web apps via HTTP/REST, without deep expertise in JSLEE development. 

Do you think USSD GW should have a separate mailing list that is focused on USSD GW setup, administration, usage and apps? Or is it better to continue riding the general mobicents-public mailing list for USSD GW topics?

Can you share a few use cases for USSD GW that are on your radar?

Ivelin

[faizan naqvi]

A few thoughts on USSD GW separate maillist.
1-- USSD GW is just a start. There will be (hopefully) SMSC and IN and other things built. Won't it get too messy to keep them as separate project in terms of code? Moreover, separate maillists.
2-- All these components rely on SS7 stack and separate mail lists would mean redundant questions and possibly parallel conversations about related issues.

What do you guys think?

--
Regards
Faizan Naqvi (Tili)

[imranrazakhan]

Hi Ivelin,

We are looking for USSD GW and expose it on SMPP protocol(To send USSD requests and receive USSD notifications over SMPP, we have to use the "ussd_service_op" TLV parameter) to our service providers.

The benefit we will get is that our current services which are available on SMPP can be easily provided over USSD and less development on Service Provider side.

Regards,

imran

On Friday, March 9, 2012 1:26:14 AM UTC+5, ivelin wrote:

Imran,

Thank you for the feedback. The new project was created in recognition of the demand for a standalone USSD GW product that can be easily administered (GUI, CLI, JMX, SNMP) and interfaced by enterprise and web apps via HTTP/REST, without deep expertise in JSLEE development. 

Do you think USSD GW should have a separate mailing list that is focused on USSD GW setup, administration, usage and apps? Or is it better to continue riding the general mobicents-public mailing list for USSD GW topics?

Can you share a few use cases for USSD GW that are on your radar?

Ivelin

[Amit Bhayani]

Thanks Guys,

Imran we have SMPP API to be exposed in road-map. This will be after the O & M web interface is done. 

Amit.

[Ivelin Ivanov]

Imran,

Would you be interested in contributing to the project so we can progress faster?

Ivelin

[hashim zayed]

It is very good idea to have an standalone USSD gateway,  this will encourage community who have only interest in ussd and not SLEE (like me) to make more cobtributions and involve more on this interesting peoject.

Hashim.

On 2012 3 8 20:26, "Ivelin Ivanov" <ivelin.atan...@gmail.com> wrote:
Imran,

Thank you for the feedback. The new project was created in recognition of the demand for a standalone USSD GW product that can be easily administered (GUI, CLI, JMX, SNMP) and interfaced by enterprise and web apps via HTTP/REST, without deep expertise in JSLEE development. 

Do you think USSD GW should have a separate mailing list that is focused on USSD GW setup, administration, usage and apps? Or is it better to continue riding the general mobicents-public mailing list for USSD GW topics?

Can you share a few use cases for USSD GW that are on your radar?

Ivelin

On Thu, Mar 8, 2012 at 2:17 AM, imranrazakhan <imranr...@gmail.com> wrote:
>
> Hi All,
>

> St...