[Steven McNeese]

Did you ever figure this out? We occasionally get a customer call saying this didn’t get a text message. We use AT&T and the customers
Have been on all carriers – even AT&T. The log shows the text went out successfully. If I run a test with the customer after the report the issue, it works fine. I have not been able to find a pattern.

I have also seen where certain customers don’t receive the message if their phone is off when we send it. This has been reported by one customer on the same carrier. It is strange because I can test the scenario on my phone with the same carrier and it works as expected. AT&T queues the message until the phone comes back online and then the SMS message is delivered.

I am interested to hear more about the cross carrier blocking if they see a lot of messages coming from the same number. We have 4 sims and send on average 30k messages a month using the 4 numbers.

Steve

[Steven McNeese]

I just tested sending to other numbers services by different phone companies. I get the message consistently regardless of the land line phone company. So, I think it is coming from our carrier we are using on the iSMS server which is AT&T. It is nice because the responding message includes the number and original message so it will be easy to find the outbound message in our database and update the error_code to indicate Invalid Number.

[Steven McNeese]

Byron,

Thanks for the quick response. Sorry for the confusion. The 1972xxxxxxx is the number i was sending to. It is my office so I just masked it out. The 112-161-1611 is the from number of a text message I received shortly after sending the original message to the land line. My assumption is that it is coming from the carrier.

In our solution, customer often give us land lines so I am trying to figure out the best way to capture this issue. I’m going to assume that the message comes from our carrier and that the format will be consistent. Then I will change the listener to look for these “Invalid Number” messages and update the status of the original outbound message.

Can you tell me what happens if the destination number does not have texting capabilities or has texting blocked? Is that a similar situation that will specific to the carrier we are using?

Thank you,

Steve

[Steven McNeese]

I have also tested through the API and the line feed is being stripped out on the receiving device.

[Steven McNeese]

Resolved. It was an issue with request validation failing because of the XML data being posted. Once I configured the web site to allow that it worked fine.

[Steven McNeese]

It appears that the API can exceed the 1232 character limitation shown in the web admin interface. What is the message length limit for the new PDU mode?

[Steven McNeese]

In PDU and/or the new web interface shows a limit of 1232 characters for the message now. Why this limit? Is this just a limit for the web admin interface or is this a limit for the HTTP/TCP API as well? If this is the new limit for PDU mode, will error code 604 get returned if the message is greater than 1232?

[Steven McNeese]

Here is the reply from support…

1. It appears that any message sent from the admin web interface gets a MSG ID of zero and only messages sent through the HTTP or TCP API get an actual MSG ID. Is this correct?

Yes, this is correct.

2. What is the maximum value for the MSG ID and what happens when this limit is reached?

The max value of Msg ID is 4,294,967,295 (Unsigned int).

3. Does the internal counter for the MSG ID ever reset?

Yes, the MSG ID will get reset on when the iSMS is factory defaulted. The msg ids are periodically saved to flash, but some msg ids can be lost if the iSMS is reset before saving to flash.

[Steven McNeese]

Ok, I think I see that MSG IDs are not assigned to messages sent from the admin web interface. All of the messages with ID 0 are sent from the web interface. Only messages sent through the API get a message ID. Is this correct?

When does this internal MSG ID get reset? What is the largest number it will have?

[Steven McNeese]

I rebooted and now it is working. Hopefully it is not an intermittent bug. Please let me know if their are known issues.

[Steven McNeese]

I upgraded to 1.51.14 and see there is a PDU option and option to concatenate mutli-part messages! This is great. Unfortunately, every message I try to send from the web interface shows an error that International numbers are supported. I am not providing an international number – just 10 digit number. I guess this is why it is a beta release of firmware. Is there a known problem with this beta release?

[Steven McNeese]

Any word on this? I am trying to understand if you support Segmentation and Reassembly (SAR) for text messages or if you are just splitting it and sending multiple messages. Sending multi-part text messages is not difficult and should be something you support. Here is some info on the User Data Heading encoding required:

Multipart User Data Header encoding

The UDH for message concatenation will only take 5 bytes, so there are 135 bytes left for the user data. When sending concatenated text messages, you can send 153 characters when using 7-bit text, when using Unicode 67 characters per part.

Byte Value Description

01 00 Information Element Identifier: Concatenated short message, 8bit reference number

02 03 Information Element Data Length (always 03 for this UDH)

03 A4 Information Element Data: Concatenated short message reference, should be same for all parts of a message

04 03 Information Element Data: Total number of parts

05 01 Information Element Data: Number of this part (1/3)

Example of a multipart message consisting of 3 parts containing 300 bytes:

SMS 1 User Data: 00 03 A4 03 01 [ 135 bytes of message data ]

SMS 2 User Data: 00 03 A4 03 02 [ 135 bytes of message data ]

SMS 3 User Data: 00 03 A4 03 03 [ 30 bytes of message data ]

[Steven McNeese]

I tested this and although it looks like it will accept message strings larger than 160 characters (1232 in web interface), it still send them as individual messages <= 160 characters split up. For example I sent a message that was 611 characters from the web admin interface and I received 4 separate messages on my iPhone (1of4), (2of4), (3of4) and (4of4). I know for a fact that the iPhone support multi-part text messages. Shouldn’t these have re-assembled into a single message on the device or am I misunderstanding the capability. My firmware on my SF800-G is 1.50.7.

[Steven McNeese]

So what is the expected release? Are you still working on new features? What are those? I found this version specifically for a request to send text messages over 160 characters. This release seems to have fixed the firmware to support this from the admin console, but the API still does not. Will there be a new version of the API that supports sending extended length text messages (multipart) via the HTTP or TCP API?

[Steven McNeese]

I am very interested in this as well. I just purchased a SF800 and would like to send text messages longer than 160 characters using the HTTP or TCP integration.

[Author]

Posts