NOWSMS Vs Logica

NOWSMS Vs Logica SearchSearch

SMS & MMS Technical Forum » NowSMS Support - SMS Issues (Product Support Only) » Archive through March 09, 2004 » NOWSMS Vs Logica « Previous || Next »
Author Message
New member
Username: Djxlord

Post Number: 3
Registered: 01-2004
Posted on Wednesday, February 11, 2004 - 04:36 pm:   

Dear Sir ,
We are using Logica API and we connect to now sms..but we are facing problems with binary sms..
as en example .. logica states that DCS in Binary = 5 while nowsms DCS = 4 ...
what we need to know does now sms support tlv parameteres ???
and is there any problem faced before in such case between logica and NOWSMS ??
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 1825
Registered: 10-2002
Posted on Wednesday, February 11, 2004 - 04:53 pm:   


I'm not sure what your conflict is with the binary DCS.

NowSMS will forward whatever DCS value you supply to the upstream provider.

I can tell you that according to the ETSI GSM 03.38 specification (you can download this spec from, a DCS value of 5 would be invalid (bits 0 and 1 are reserved when bit 6 and 7 are 0 and bit 4 is 0). So while NowSMS will accept a message with DCS=5, an upstream provider might reject a message that has a DCS value of 5, as it is invalid.

The normal DCS value for a binary message is 4, although F5 is frequently used for Nokia Smart Messaging.

What Logica spec is telling you that the DCS should be 5? Perhaps it is referring to something other than the DCS?

Regarding TLV. The current version does not support any TLV as an SMPP server. (It does support the message_payload TLV as an SMPP client.)

We do have a patch that we can send you which adds support for the message_payload TLV when NowSMS is an SMPP server. If you would like this patch, please e-mail to request it.

Other than that, we are not currently supporting any other TLV. (Although we will be supporting message_state and receipt_message_id to some extent in an upcoming version.)

What TLV do you want to use?

We've found that most applications build the UDH itself.

But we are interested in improving our SMPP server implementation. So I'm curious ... can you give me an example of what TLV you are trying to use?

New member
Username: Djxlord

Post Number: 4
Registered: 01-2004
Posted on Thursday, February 12, 2004 - 05:11 am:   

This is the Code we use ..
so when we check smsout.log we get errors
either we get a DCS=5 value and no other parameteres logged or recieved by NOWSMS
and if we change DCS Value we get LONG UDH Length

if (itsBinary Message...then)

// create a buffer for the message payload
ByteBuffer payload = new ByteBuffer();
String b = new String(message);
byte[] bytes2 = hexStringToBytes(b);
ByteBuffer toneData=new ByteBuffer(bytes2);
// simply append the ring tone data to the message payload
// we send all the data as a message payload
// you must set the esme class to indicate that the message
// contains UDH
// the coding is GSM specific
//This function converts hexStringToBytes for a particular Message
private static byte[] hexStringToBytes(String hex) throws NumberFormatException
final String hexChars = "0123456789ABCDEF";
hex = hex.substring(2);

hex = hex.toUpperCase();
int len = hex.length()/2;
byte[] ret = new byte[len];
int i = 0;

for(int n=0; n<len; n ++)
int hiBit=0;
int loBit=0;
hiBit = hexChars.indexOf(hex.charAt(i++));
loBit = hexChars.indexOf(hex.charAt(i++));

if(hiBit != -1 && loBit != -1)
ret[n] = (byte) (((hiBit << 4)&0xf0) | (loBit&0x0f));
ret[n] = (byte) 0;

return ret;


Code contains 2 parts...function and actual binary sms sending part
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 1869
Registered: 10-2002
Posted on Thursday, February 12, 2004 - 01:57 pm:   

The DCS in the example appears to be F5, which is fine.

Rather than me sorting through the code and trying to understand it, it's usually easier for me to look at the raw packet that it generates to understand what is going on.

Manually edit SMSGW.INI, and under the [SMSGW] section header, add Debug=Yes. Restart the SMS service.

Repeat your submit attempt, and then e-mail the SMPPDEBUG.LOG to, or post in reply here.

In this particular case though, as I scan the code again, I think I know what the problem is. The code appears to be using the message_payload TLV, and while we have been supporting this interface as a client talking to an SMPP SMSC for quite some time, we haven't had support for it as a server.

As your e-mail address is attached to the message, I will e-mail you an update that includes message_payload TLV support, which should take care of the problem.


Login Login / Register Logout Logout Search Last 30 Days Topics Topics