jayriq / smscgateway Goto Github PK

If Mt SMS fails due to memory full or subscriber switched off, SMSC should 
register MSISDN in Message Waiting Data into the HLR by sending 
MAP-REPORT-SM-DELIVERY-STATUS message.

What steps will reproduce the problem?
1.Create Clone:git clone https://code.google.com/p/smscgateway/
2.Compile using mvn clean compile or mvn clean install
3.Generate compilation error.

What is the expected output? 
Project is compiled successfully

What do you see instead?
[ERROR]     Unresolveable build extension: Plugin 
org.mobicents.tools:maven-eclipse-plugin:1.0.1.FINAL or one of its dependencies 
could not be resolved: Failure to find
 org.mobicents.tools:maven-eclipse-plugin:jar:1.0.1.FINAL in http://192.168.200.35:8080/artifactory/plugins-release was cached in the local repository, resolution will
not be reattempted until the update interval of central has elapsed or updates 
are forced -> [Help 3]
org.apache.maven.plugin.PluginResolutionException: Plugin 
org.mobicents.tools:maven-eclipse-plugin:1.0.1.FINAL or one of its dependencies 
could not be resolved: Failure
 to find org.mobicents.tools:maven-eclipse-plugin:jar:1.0.1.FINAL in http://192.168.200.35:8080/artifactory/plugins-release was cached in the local repository, resoluti
on will not be reattempted until the update interval of central has elapsed or 
updates are forced
        at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:215)
        at org.apache.maven.project.DefaultProjectBuildingHelper.resolveExtensionArtifacts(DefaultProjectBuildingHelper.java:377)
        at org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm(DefaultProjectBuildingHelper.java:237)
        at org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled(DefaultModelBuildingListener.java:106)
        at org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire(ModelBuildingEventCatapult.java:43)
        at org.apache.maven.model.building.DefaultModelBuilder.fireEvent(DefaultModelBuilder.java:1053)
        at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:388)
        at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:371)
        at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:560)
        at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:352)
        at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:636)
        at org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:585)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:234)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)


What version of the product are you using? On what operating system?
OS: Windows 7
Java: Java 1.7
maven : 3.0.5

Kindly request you all to provide some inforamtion.

Add basic support for SMSC like
1) Receive SMS from user - Mo SMS
2) Send SMS to intended user - Mt SMS

Flexibility to change the source/destination MSISDN as per configured rule.


For example conversion of number from national format to international format 
etc.

SMSC should send back status of received SUBMIT_SM to ESME via SMPP.

1) Send back DELIVERED as soon as SMS is delivered to intended user.
2) Send back FAILURE if delivering SMS fails

The status should be taken care only if Submit PDU's registered_delivery
 is set to true.

SMSC should lookup black list to know if user is allowed to send SMS and 
destined user is allowed to receive SMS.

What steps will reproduce the problem?
1. Setup a bind_transmit from ESME 
2. Send a submit_sm
3. SMSC will send deliver_sm on the same bind

What is the expected output? What do you see instead?
I think that it should send it down a bind_receiver.

What version of the product are you using? On what operating system?
Bleeding edge.

Please provide any additional information below.

Ok, below we setup two separate binds... the deliver_sm comes on the 
transmitter bind. Also, if we unbind after submit_sm_resp, we don't get a 
deliver_sm.

133.440942 172.16.29.36 -> 172.16.29.19 SMPP SMPP Bind_receiver
133.442286 172.16.29.19 -> 172.16.29.36 SMPP SMPP Bind_receiver - resp: "Ok"
137.791958 172.16.29.36 -> 172.16.29.19 SMPP SMPP Bind_transmitter
137.792981 172.16.29.19 -> 172.16.29.36 SMPP SMPP Bind_transmitter - resp: "Ok"
137.793746 172.16.29.36 -> 172.16.29.19 SMPP SMPP Submit_sm
137.795041 172.16.29.19 -> 172.16.29.36 SMPP SMPP Submit_sm - resp: "Ok"
140.741751 172.16.29.19 -> 172.16.29.36 SMPP SMPP Deliver_sm
147.795355 172.16.29.36 -> 172.16.29.19 SMPP SMPP Unbind
147.795690 172.16.29.19 -> 172.16.29.36 SMPP SMPP Unbind - resp: "Ok"

JMX should be registered exposing the SMSC Properties and easily accessible 
from SBB's.

SMSC is not handling SMS lower than 160 chars as total length exceeds max MSU 
length.

This should be handled by sending empty BEGIN and waiting for Dialog to be 
ACCEPTED and then sending SUBMIT pdu in CONTINUE so as to fit all the chars. 

We want to build SMPP Gateway that terminates incoming SMPP connections and 
dispatches the SMS to different SMS-C gateways based on configurable routing 
rules.    

Could you please describe if the current library supports incoming SMPP 
interface also (SMPP server) ? as most of the libraries normally support only 
the outgoing SMPP interface ( in other words SMPP client)  

Expose statistics like
1) How many Mo SMS received
2) How many Mt SMS sent successfully, failure (permanent, temporary)
3) How many SRI sent (response received or not)

etc

If called user is provisioned, user is customer of operator and SMSC initiates 
Mt module

If not, may be SMSC can route to different ESME which can act as aggregator and 
has connection to different operator's SMSC 

SMSC should be flexible to integrate with charging system via Diameter protocol

Handle AlertServiceCentreRequest incoming request and send stored SMS for 
MSISDN if any.

What steps will reproduce the problem?
1. Send an MT-ForwardSM
2. Take a PCAP trace
3. Timestamp is wrong, showing an older tade

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. Just download the master branch and try to build it

What is the expected output? What do you see instead?
The expected output is SUCCESSFULL, but we got an ERROR.

What version of the product are you using? On what operating system?
1.0.0.ALPHA1. Linux, Ubuntu 11.04.

The problems is inside two pom.xml. Below is how I fixed it.

   /core/bootstrap/pom.xml
   Remove: <artifactId>oam</artifactId>
   Add:    <artifactId>smsc-cli</artifactId>

   /core/slee/smpp-server-ra/ratype/pom.xml
   Remove: <artifactId>events</artifactId>
   Add:    <artifactId>smpp-server-ra-events</artifactId>

As of now these properties are placed in smsc.properties file. Its better to 
make these configurable via CLI and persist in SmscManagement_smsc.xml file.

SMSC should send back status of received SMS.

1) Send back PENDING as soon as SMSC receives the SMS
2) Send back DELIVERED as soon as SMS is delivered to intended user.

The status should be taken care only if Submit PDU's StatusReportRequest is set 
to true.

SMSC should be flexible to allow adding routing rule depending on destination 
number.

For example SMS is sent to number 1234, and administrator configured routing 
rule for 1234 to be routed over SMPP to Connection1, SMSC should send SMS to 
corresponding ESME via SMPP

Detailed information about the new feature request

1. What motivated the request:
Customer wants to send longer than 160 character sms.

2. Link to related public forum or mailing list discussion:

3. Describe functionality and API (if applicable)
Require handling concatenated SMS

SMSC should execute batch process every night and purge all pending SMS whose 
validity period is expired. 

Irrespective of what data_coding is set in SUBMIT_SM, when SMSC is sending 
mt-forwardSM, the TP-DCS field doesn't change.

CLI command to configure the source/destination MSISDN conversion rule

In case of Mt Forward SMS, if HLR replies user not available or no memory in 
user hand-set, SMSC should persist the SMS and register user with HLR waiting 
list (ReportSMDeliveryStatusRequest).

Once HLR notifies about availability of user (AlertServiceCentreRequest), SMSC 
should try to send SMS again (Mt Forward SMS) 

Detailed information about the new feature request

1. What motivated the request:

In a clustered SMSC environment, where multiple SMSC are service requests, the 
message_id returned in a submit_sm_resp may be duplicated across multiple SMSC. 
This can cause confusion to 3rd party, who may be expecting completely unique 
message_id.

Perhaps a configurable value can be prefix/suffix to the message_id before it 
is returned. Keep in mind that the overall length of the message_id generated 
by the system will need to be reduced by the length of the configurable value 
so as to keep overall length within the spec. For our purposes a single 
character is fine and would allow (A-Z,0-9) 36 unique smsc in a cluster. A dual 
character would allow 36^2.

According to the SMPP 3.4 spec

submit_sm_resp has message_id which is a Variable length 65, C Octet String
This field contains the SMSC message ID of the submitted message. It may be 
used at a later stage to query the status of a message, cancel or replace the 
message.

5.2.23 message_id
The unique message identifier reference assigned by the SMSC to each submitted 
short
message. It is an opaque value and is set according to SMSC implementation. It 
is returned by the SMSC in the submit_sm_resp, submit_multi_resp, 
deliver_sm_resp  and  data_sm_resp PDUs and may be used by the ESME in 
subsequent SMPP operations relating to the short message, e.g. the ESME can use 
the  query_sm operation to query a previously submitted message using the SMSC 
message_id as the message handle.

adapt to new jSS7 CLI

When SRI is sent for MSISDN in short span, the SRI Response is always same. 
Should SMSC cache SRI Response and use same value for consecutive Mt SMS 
destined for same MSISDN? 

Decide the basic skeleton for SMSC on which all other logic will be developed

SMSC should generate CDR for each SMS received/forwarded.

1) Decide if the CDR should be persisted in RDBMS or non-rdbms database like 
Cassandra.

2) Decide the schema of CDR

SMSC should have support for SMPP protocol to send/receive SMS from SMSC to 
External Short Messaging Entity (ESME)

As of now SRI and MtSMS is restricted to V3. If the far end replies ACN not 
supported, SMSC drops message.

Instead SMSC should re-attempt to send SRI/MtSMS with Alternate ACN suggested 
by DialogReject event.

When user submits SMS (user has requested request status reports) and reaches 
to SMSC; SMSC should immediately send PENDING MtSMS to originator.

Use SmsStatusReportTpdu in MtSMS to send PENDING status 

What steps will reproduce the problem?
1. install mobicents slee and deploy ss7
2. download smscgateway git
3. compile and install using "mvn clean install"

What is the expected output? What do you see instead?
Successful compilation and installation

What version of the product are you using? On what operating system?
Ubuntu, 

Please provide any additional information below.

SMSC should send back status of received SMS from ESME.

Detailed information about the new feature request

1. What motivated the request:
Customer wants to send arabic and other text

2. Link to related public forum or mailing list discussion:

3. Describe functionality and API (if applicable)
Support Unicode

SMSC Server shouldn't accept connection from any ESME. CLI should expose 
command to allow admin to add ESME configuration. 

Feature to add/provision the user in the SMSC. Add properties for user like 
Pre-Paid or Post-Paid.