I am trying to use the API with mblox - they require a couple extra parameters, but I can't seem to activate support for parameters:
13:49:33,304 INFO [SmppTest] Binding to the SMSC
13:49:33,304 INFO [SmppTest] Binding to the SMSC
13:49:33,376 WARN [APIConfig] Could not find API properties to load
13:49:35,401 INFO [Connection] setInterfaceVersion SMPP version 3.4
13:49:35,423 INFO [Connection] Binding to the SMSC as type 1
13:49:35,424 INFO [Connection] Opening network link.
13:49:35,424 INFO [TcpLink] Opening TCP socket to smpp.psms.us.mblox.com/63.236.51.130:3204
13:49:35,451 INFO [Connection] Setting state 1
13:49:35,550 INFO [Connection] Setting state 2
13:49:35,577 WARN [Connection] Disabling optional parameter support as no sc_interface_version parameter was received
It seems like optional parameters are being explicitly disabled for some reason. Can anyone help? Has anyone actually successfully used the API with mblox?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just wanted to say thanks -- turns out mblox is not setting that param, even though they require the use of optional params - I'll be dropping them a polite note on the subject. I created a connection that forces the use of optionals regardless and tested again, this time all works well.
Thanks, this API is a godsend for us smpp newbs!
BJ
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello fellow mBlox'r! I've been trying to connect to mBlox's PSMS service to no avail (can get to "DirectPlus" though). Was wondering if you would mind posting your connection code to the forum (minus auth creds of course) as it might assist people like myself in figuring out how to get to mBlox.
(Might be good to have a repo somewhere with Hello World apps for all the major SMSCs)
Thanks!
Richard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Richard, I tried to respond to your email via sourceforge but it bounced. Here's what it said:
Mblox uses some 'optional' parameters to enable sending via a psms connection, specifically, you need to know the 'carrier id', as you've no doubt encountered. Mblox smpp implementation does not properly send sc_interface_version, since smppapi is spec compliant, and the spec says to assume NO optional param support, you have a catch 22.
I compiled my own version of smppapi with the following changes:
First, see ie/omk/smpp/Connection.java
1) add one or more constructors allowing you to pass a new boolean parameter 'forceOptParamSupport' save this as a private attribute.
2) change the method 'readNextPacketInternal' to force the support - find this block and add the new code in the 'else' section:
// Read the version of the protocol supported at the SMSC.
Number n = (Number) resp.getOptionalParameter(Tag.SC_INTERFACE_VERSION);
if (n != null) {
SMPPVersion smscVersion = SMPPVersion.getVersion(n.intValue());
if (logger.isDebugEnabled()) {
logger.debug("SMSC reports its supported SMPP version as "
+ smscVersion.toString());
}
// Downgrade this connection's version if the SMSC's version is
// lower.
if (smscVersion.isOlder(this.interfaceVersion)) {
logger.info("Downgrading this connection's SMPP version to "
+ smscVersion.toString());
setInterfaceVersion(smscVersion);
}
} else {
// Spec requires us to assume the SMSC does not support optional
// parameters
if (forceOptParamSupport) {
logger.warn("No sc_interface_version parameter was received - forcing optional param support");
} else {
this.supportOptionalParams = false;
logger.warn("Disabling optional parameter support as no sc_interface_version parameter was received");
}
}
Next, I added the mblox tag declarations, see ie/omk/smpp/message/tlv/Tag.java
I added:
public static final Tag MBLOX_TARRIF_CODE = new Tag(0x1403, byte[].class, 1, 5);
public static final Tag MBLOX_OPERATOR_CODE = new Tag(0x1402, byte[].class, 5);
I recompiled the api. All you need to do to get mesages out is to set up the message as usual, adding the optional params as folleows:
SubmitSM sm = (SubmitSM) myConnection .newInstance(SMPPPacket.SUBMIT_SM);
// set other properties here...
sm.setOptionalParameter(Tag.MBLOX_TARRIF_CODE, "0".getBytes());
sm.setOptionalParameter(Tag.MBLOX_OPERATOR_CODE, defaultCarrier.getBytes());
Hope this helps!
B.J.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In SMPP version 3.4, a parameter was added to the bind response packets which allowed the SMSC to identify the version of the protocol that it supported - this parameter is supplied in an optional parameter. If that optional parameter is supplied by the SMSC, the binding client is required to honour the given version number. In the event that the SMSC supports a newer version of the protocol, the client is free to proceed. In the event that the SMSC reports an earlier version than that supplied by the client in its bind request packet, the client is required to downgrade the version it is using.
Of course, SMPP v3.3 did not support optional parameters and therefore a V3.3 SMSC cannot report its supported version to a binding client. In the case where an SMSC does not supply the sc_interface_version optional parameter in its bind response packet, the specification requires the client to assume the SMSC does not support optional parameters. (Section 3.4, page 44 of the SMPP v3.4 specification).
If your SMSC provider is not returning the sc_interface_version optional parameter in its bind response packets but is still requiring their use, then their implementation is in violation of the spec. Of course, that doesn't help you in the immediate - if you want to prevent the API from disabling the use of optional parameters, then you'll want to have a look at the handleBindResp method of ie.omk.smpp.Connection.
oran
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am trying to use the API with mblox - they require a couple extra parameters, but I can't seem to activate support for parameters:
13:49:33,304 INFO [SmppTest] Binding to the SMSC
13:49:33,304 INFO [SmppTest] Binding to the SMSC
13:49:33,376 WARN [APIConfig] Could not find API properties to load
13:49:35,401 INFO [Connection] setInterfaceVersion SMPP version 3.4
13:49:35,423 INFO [Connection] Binding to the SMSC as type 1
13:49:35,424 INFO [Connection] Opening network link.
13:49:35,424 INFO [TcpLink] Opening TCP socket to smpp.psms.us.mblox.com/63.236.51.130:3204
13:49:35,451 INFO [Connection] Setting state 1
13:49:35,550 INFO [Connection] Setting state 2
13:49:35,577 WARN [Connection] Disabling optional parameter support as no sc_interface_version parameter was received
It seems like optional parameters are being explicitly disabled for some reason. Can anyone help? Has anyone actually successfully used the API with mblox?
Oran,
Just wanted to say thanks -- turns out mblox is not setting that param, even though they require the use of optional params - I'll be dropping them a polite note on the subject. I created a connection that forces the use of optionals regardless and tested again, this time all works well.
Thanks, this API is a godsend for us smpp newbs!
BJ
BJ,
Hello fellow mBlox'r! I've been trying to connect to mBlox's PSMS service to no avail (can get to "DirectPlus" though). Was wondering if you would mind posting your connection code to the forum (minus auth creds of course) as it might assist people like myself in figuring out how to get to mBlox.
(Might be good to have a repo somewhere with Hello World apps for all the major SMSCs)
Thanks!
Richard, I tried to respond to your email via sourceforge but it bounced. Here's what it said:
Mblox uses some 'optional' parameters to enable sending via a psms connection, specifically, you need to know the 'carrier id', as you've no doubt encountered. Mblox smpp implementation does not properly send sc_interface_version, since smppapi is spec compliant, and the spec says to assume NO optional param support, you have a catch 22.
I compiled my own version of smppapi with the following changes:
First, see ie/omk/smpp/Connection.java
1) add one or more constructors allowing you to pass a new boolean parameter 'forceOptParamSupport' save this as a private attribute.
2) change the method 'readNextPacketInternal' to force the support - find this block and add the new code in the 'else' section:
// Read the version of the protocol supported at the SMSC.
Number n = (Number) resp.getOptionalParameter(Tag.SC_INTERFACE_VERSION);
if (n != null) {
SMPPVersion smscVersion = SMPPVersion.getVersion(n.intValue());
if (logger.isDebugEnabled()) {
logger.debug("SMSC reports its supported SMPP version as "
Next, I added the mblox tag declarations, see ie/omk/smpp/message/tlv/Tag.java
I added:
public static final Tag MBLOX_TARRIF_CODE = new Tag(0x1403, byte[].class, 1, 5);
I recompiled the api. All you need to do to get mesages out is to set up the message as usual, adding the optional params as folleows:
SubmitSM sm = (SubmitSM) myConnection .newInstance(SMPPPacket.SUBMIT_SM);
// set other properties here...
sm.setOptionalParameter(Tag.MBLOX_TARRIF_CODE, "0".getBytes());
sm.setOptionalParameter(Tag.MBLOX_OPERATOR_CODE, defaultCarrier.getBytes());
Hope this helps!
B.J.
In SMPP version 3.4, a parameter was added to the bind response packets which allowed the SMSC to identify the version of the protocol that it supported - this parameter is supplied in an optional parameter. If that optional parameter is supplied by the SMSC, the binding client is required to honour the given version number. In the event that the SMSC supports a newer version of the protocol, the client is free to proceed. In the event that the SMSC reports an earlier version than that supplied by the client in its bind request packet, the client is required to downgrade the version it is using.
Of course, SMPP v3.3 did not support optional parameters and therefore a V3.3 SMSC cannot report its supported version to a binding client. In the case where an SMSC does not supply the sc_interface_version optional parameter in its bind response packet, the specification requires the client to assume the SMSC does not support optional parameters. (Section 3.4, page 44 of the SMPP v3.4 specification).
If your SMSC provider is not returning the sc_interface_version optional parameter in its bind response packets but is still requiring their use, then their implementation is in violation of the spec. Of course, that doesn't help you in the immediate - if you want to prevent the API from disabling the use of optional parameters, then you'll want to have a look at the handleBindResp method of ie.omk.smpp.Connection.
oran