| Payload Messages |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through September 15, 2006 ⬆ |
◄ ► |
| Author | Message | |||
| sam New member Username: Samdsouza Post Number: 1 Registered: 08-2006 |
Hi Bryce Wanted to Understand how do we send messages as Payload via NowSMS 2006? I have gone through most of the message board and found the following: NowSMS to use optional SMPP TLV (tag/length/value) parameters for signaling that a long text message is segmented over multiple physical messages. (The parameter appears under "Advanced Settings" when you configure an SMPP connection. And it is titled "Use TLV parameters for port numbers and segmentation". It may be worth trying that setting in conjuction with the following option UNchecked: Send Long Text Messages using 7-bit encoding. My question is how do we set/define the following parameters in the smsgw file if i want all the messages to be sent as payloads including binary and long messages: tag/length/value parameters I have found references to mblox setttings but no references if we want to send binary/unicode/long messages as payloads. Waiting in anticipation of your reply. Regards Sam | |||
| sam New member Username: Samdsouza Post Number: 2 Registered: 08-2006 |
Hi Just a addition to the above. The NowSMS 2006 documentation mentions: "and segmentation will be encoded in the sar_msg_ref_num, sar_total_segments, and sar_segment_seqnum parameters." Does the above segmentation happens automatically or do we need to specify the above 3 parameter deatils in the smsgw file? Regards Sam | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6306 Registered: 10-2002 |
Sam, I don't understand what you're asking. Are you saying that instead of putting message data in the short_message field, you want it put in the optional message_payload parameter instead? We don't have an option to do this...basically, we've never had a reason to need to this. We do use this parameter for WAP push messages when WDP adaptation is enabled, but that applies only for WAP push messages. Are you sure you need to do this? I'm curious as to why. -bn | |||
| sam New member Username: Samdsouza Post Number: 3 Registered: 08-2006 |
Hi Bryce Thanks for your reply. I was testing a SMPP connection. This smpp connection is on ver 3.4. The short text messages work fine. But the issue is on unicode/binary/long messages. I tried testing a 67 unicode character sms but the full message didnt come on to the handset. The message got truncated at a point with a "square box". The phone is capable of receiving unicode messages and the same message comes in properly if sent via a handset. I also tested a 2 part long message. Here also the full message didnt come in properly. The characters were fine but instead of 176 characters only 170 characters landed on the handset. After checking with the Operator they told me that they expected unicode/binary/long messages to be sent as payload to their SMSC and not with the regular UDH codings. According to them the UDH is included in the message payload itself and it shouldnt be sent as a seperate parameter. So assuming that i want to send unicode/binary/long messages to this 3.4 smpp connection as payload only how do i do that? Thanks Sam | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6352 Registered: 10-2002 |
Hi Sam, Apologies for the delay in response. I fell into a time warp. Under "Advanced Settings" for the SMPP connection in NowSMS, try setting "Use TLV parameters for port numbers and segmentation". Some providers like the segmentation to be performed using these optional parameters instead of directly via UDH. If that doesn't work, we can look into a no-segmentation option using the message_payload parameter. But I would expect a provider that asked you to use message_payload for long messages to also support segmentation via these optional headers. -bn | |||
| sam New member Username: Samdsouza Post Number: 4 Registered: 08-2006 |
Hi Bryce Thanks for your reply. I tried senidng unicode/long messages via "Use TLV parameters for port numbers and segmentation". Didnt work out. Messages didnt land properly. Do I need to specify anything in the SMSGW file after i use the "Use TLV parameters for port numbers and segmentation"? I checked the smsout file when "Use TLV parameters for port numbers and segmentation" was on and found that it was going out with the UDH parameters only. In short there was no difference in the outgoing sms. Regards Sam | |||
| sam New member Username: Samdsouza Post Number: 5 Registered: 08-2006 |
Hi Bryce My mistake on the above post. With "Use TLV parameters for port numbers and segmentation" on and all the other parameters unchecked on SMPP Advanced Tab I get the following error: Retry Pending - ERROR: Optional Parameter not allowed And the messages are stuck on my desktop. Regards Sam | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6355 Registered: 10-2002 |
Hi Sam, Thanks. I took a closer look at how these different SMPP configuration options work ... as well as how they were intended to work. It looks like this "Use TLV parameters for port numbers and segmentation" option does not encode messages properly. This may or may not be the problem that you are experiencing when you enabled this setting. I say may or may not ... because trying this setting with your service provider was really just a guess anyway. We're going to correct the encoding problem that I observed with this setting. But I also wanted to take a closer look at these settings to see if there was a way that we could accomplish what you had originally requested. That is, long messages to be submitted in a single request instead of as multiple segments, using the optional SMPP message_payload parameter. A side effect of the "Use WDP Adaptation" option is that all long messages, including long text messages, are submitted in a single request instead of as multiple segments. However, I observed that when a long text message was submitted in this manner, it was encoded in the SMPP short_message parameter. However, if the length was over 254, the length field for this parameter would be invalid. (And many SMSCs would truncate before this limit.) So we've fixed this logic, where if a long message is submitted as a single request, we use the message_payload parameter instead. The "Use WDP Adaptation" setting will trigger long messages, including long text messages, to be sent in a single request. Download the update at http://www.nowsms.com/download/20060815.zip, and give that update a try. I'd suggest first trying the "Use WDP Adaptation" setting checked, with "Use TLV parameters" UNchecked. After that, also try "Use WDP Adaptation" UNchecked, with "Use TLV Parameters" checked (as I believe your most recent problems may have been caused by a different error that has been fixed). -bn | |||
| sam New member Username: Samdsouza Post Number: 6 Registered: 08-2006 |
Hi Bryce Thanks for the details. Installed the patch. Following Observations: 1. trying the "Use WDP Adaptation" setting checked, with "Use TLV parameters" UNchecked. Got the following error on long message: Retry Pending - ERROR: Invalid Parameter Length. 2. "Use WDP Adaptation" UNchecked, with "Use TLV Parameters" checked Got the following error on long message: Retry Pending - ERROR: Optional Parameter not allowed I have demo version 2006.08.15 showing on my NowSMS after I installed the patch. Regards Sam | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6386 Registered: 10-2002 |
Hi Sam, I'm leaning toward the thought that your service provider does not actually support long messages. Scenario 1 ... Use "WDP Adaptation" checked, "Use TLV parameters" unchecked ... should be submiting the long message in its entirety in the "message_payload" parameter. (If the message is 160 characters or less, it goes into the "short_message" parameter ... longer it goes into "message_payload".) I can only assume that the "invalid parameter length" is referring to the length of this particular parameter. The other "Optional parameter not allowed" suggests that they don't support any of the parameters related to segmentation (used instead of UDH with NowSMS performing the segmentation). So I don't know what else to try. You probably need more guidance from the provider, as I think we've tried all of the different options that someone might logically try to implement this. Going back to one of your earlier posts ... the original behaviour you observed is extremely unusual:
This is odd, because the limit in a single SMS for a Unicode message is 70 unicode characters. A 67 unicode character message should not present any unique issues.
As the message is longer than 160 characters, NowSMS would have segmented the message and included UDH for the segmentation. The first segment would have had 153 characters, and the remainder would be in the next segment. I think it is very strange that you received 170 out of 176 characters. This suggests that the segmentation headers in the UDH are indeed being understood ... and that the receiving handset did perform reassembly based upon these headers. Looking closer at this 176 character message. Is it the last 6 characters that are missing? Or are there also some other charcters missing from the middle of the message? I could be wrong, but it sounds like the SMSC that you are connecting to has some bugs. My thought is that the advice that you were given about putting the entire message in the message_payload is wrong. I think that they expect the message to be sent like it was originally, with the submitting client segmenting long messages and including UDH ... but that there are bugs in how the SMSC handles messages that contain both UDH and text ... and in how the SMSC handles Unicode messages over a particular length. Maybe some more testing of patterns of which characters are missing might reveal a pattern that could give us some more clues ... but it does look like bugs on the SMSC side to me. -bn | |||
| sam New member Username: Samdsouza Post Number: 7 Registered: 08-2006 |
Hi Bryce Thanks for your reply. Will test it and update you. Regards Sam | |||
| sam New member Username: Samdsouza Post Number: 8 Registered: 08-2006 |
Hi Bryce Thanks for your efforts. Indeed its an issue at the Operators SMSC. Thanks for your time. There are few more queries: 1. 2 way sms: I have seen that we can define a user on nowsms users list and give him access via SMPP to recevie sms. Is there any way where I can define a user on nowsms and give him access via HTTP using the 2 way sms command? I mean can we authenticate the user first by the nowsms user list and then pass on the incomming sms to the user? Also I notice that we can have keywords defined for a particular modem for incomming and then pass it to the user via the HTTP using the 2 way sms command. Can this be done on SMPP? I notice that it cant be done via SMPP for specific keywords. 2. 2 way by HTTP: I have seen that we can use SMPP Receive Connection to get Incomming messages to nowsms. Can we use a HTTP URL provided by the Operator to receive Incomming messages and then get it processed by nowsms? Regards Sam | |||
