| Can someone please explain how this config setting works? |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through October 31, 2007 ⬆ |
◄ ► |
| Author | Message | |||
| Siak Cheong New member Username: Scheong Post Number: 1 Registered: 09-2007 |
I'm trying to find out how the 'Encode text message with 7-bit packed encoding' and 'Encode long text message with 7-bit packed encoding' configuration setting work behind the scene before enabling them for our production gateways. Can someone explain them in detail, please? Thanks! | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7428 Registered: 10-2002 |
Hi, We recommend changing those settings only if you are experiencing a problem where text messages are received as garbage. Basically, the SMPP specifications are a little vague on some issues, and some providers have implemented things in different ways. When an actual SMS message is sent over the air, it is encoded in a 7-bit packed encoding format. Up to 160 7-bit text characters are encoded into 140 8-bit bytes. Usually, when a text message is sent using the SMPP protocol, each character is represented in an 8-bit byte. But there are a few service providers out there (most of them using older software based upon SMPP v3.3) who expect the text message to be encoded in the 7-bit packed format. So basically, if you send a text message and it is received as garbage, then you should try enabling this setting. But, as I have said, it is very rare that you would need to enable this setting ... and if you need to, you would know immediately that you have to because all of the text messages you send would be received as garbage. The 'Encode long text message with 7-bit packed encoding' setting is a little trickier. If you send a text message longer than 160 characters and it is received as garbage, then you should try enabling this setting. Sending long text messages requires that a binary user data header (UDH) be included at the start of the message. Some SMPP servers get confused if you have a binary UDH followed by text. (Note: NowSMS applies this "long text message" setting for any text messages that include UDH, which means that it applies to EMS messages as well as long text messages.) In either case, I would only enable one (or both) of these settings if you consistently see garbage text for either standard or long text messages. For long text messages, there is another configuration option that is sometimes required ... "Use TLV parameters for port numbers and segmentation". SMPP v3.4 defines some optional parameters that can be used for segmentation of long text messages ... and some providers prefer that you use this format instead of UDH encoding. But basically, the only way to know which options you require for a particular provider is to try. -bn | |||
| Siak Cheong New member Username: Scheong Post Number: 2 Registered: 09-2007 |
What I need to find out is if either of these options are enabled, 1) if the incoming SMS is not 7-bit encoded, will the gateway strip out the 8th bit out of each incoming byte to form the 7-bit encoded outgoing SMS? 2) if the incoming SMS is already 7-bit encoded, will the gateway strip things as in 1) (and mess things up), or leave things intact? Will there be any header change on the outgoing SMS? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7494 Registered: 10-2002 |
Those settings apply primarily to outgoing messages. For incoming messages, the behaviour can vary somewhat by NowSMS version. For example, there are some SMSCs that want you to use 7-bit encoding for messages outgoing to that SMSC. However, they present 8-bit encoding for incoming messages. So NowSMS tries to auto-determine the format of incoming messages. I think I would have to defer to one of the statements that I made above: I would only enable one (or both) of these settings if you consistently see garbage text for either standard or long text messages. Are you experiencing a particular problem? I could probably provide better insight regarding an actual problem. -bn | |||
| Siak Cheong New member Username: Scheong Post Number: 3 Registered: 09-2007 |
The reason for these questions is that we need to adopt 7-bit encoding to save transmission cost (squeezing 160 characters in 1 SMS, rather than 140). We need to get an accurate answer to understand whether our partner who writes SMS sender code for us will need to encode SMS in 7-bit to accomplish our goal, or to leave things in 8-bit on sending into our NOWSMS gateway and let the Gateway 'translates' them. As we aren't writing the code but need to provide the spec, and we don't have the code to test how the 7-bit encoding works without having the SMS sender written, it's a catch22 that your insights on what the NOWSMS does internally with these options will help us determine the way to go. | |||
| Siak Cheong New member Username: Scheong Post Number: 4 Registered: 09-2007 |
Also, should we determine that we need our partner to write the SMS sender code with 7-bit encoding, I don't seem to find a way to have these settings configured for just incoming SMS into the NOWSMS Gateway. Can I assume these settings, when enabled, apply automatically to outgoing SMS too? I believe the T-Mobile & Vodafone SMSCs to which our gateways connect are able to receive 8 bit SMS from us fine. I am not sure if they'll work when we suddenly send them 7-bit SMS...any suggestions? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7504 Registered: 10-2002 |
Ok, I think I understand why you are asking now. You do not need to be concerned with this. The 7-bit encoding will happen automatically. If the SMSC accepts 8-bit encoding, they will accept 160 8-bit characters in the SMS submission. When the SMSC actually sends the message over the air, the SMSC will perform the 7-bit encoding to fit the 160 characters into 140 bytes. The only reason that you would need to change this particular setting in NowSMS was if the SMSC to which you are connecting expected the encoding to be performed before the message is submitted to the SMSC. It is very rare to encounter this requirement. -bn | |||
