Destination Port does not work

Destination Port does not work SearchSearch
Author Message
William Law
New member
Username: Wlaww

Post Number: 1
Registered: 03-2009
Posted on Monday, April 06, 2009 - 10:26 pm:   

Hi,

My name is William Law. I have downloaded your trial version.

My purpose is to send an SMS through your nowsms gateway/web interface to a java midlet in a cell phone via a GSM modem.
I need to specify a destination port in your web interface. My java midlet listens to the destination port and display the SMS.

I have tried many times with your destination port but my midlet cannnot receive the SMS. I don't know whether your destination port
does not work or my midlet has a problem. Can you help me to figure out what is the problem?

I attach the java midlet and a screen shot of your web interface for your reference.

Thanks,

William Law
application/octet-streamSMSServer - java midlet Receive SMS
SMSServer.java (1.9 k)

application/vnd.openxmlformats-officedocument.wordprocessingml.documentNowSMS6001 - NowSMS web interface
NowSMS6001.docx (163.6 k)
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 671
Registered: 08-2008
Posted on Monday, April 06, 2009 - 11:06 pm:   

Hi William,

What type of SMSC connection are you using to send the SMS message that contains port addressing?

Please see the following thread where I offer some suggestions regarding different configuration options for connecting via SMPP providers:

http://support.nowsms.com/discus/messages/1/24969.html

Basically, there are 3 different configuration options in SMPP environments that can impact messages that include port addressing, and there is no way to know ahead of time which format your provider expects (if they support it at all). That thread discusses those SMPP options.

Sending a message that includes port addressing also works very similar to sending a long text message. Can you send a long text message via NowSMS and have it be received correctly (as a single long message) by the SMS client in the mobile phone? If so, that is a good sign that the headers are passing through correctly. If the phone sees multiple messages, then something is interfering with the headers.

So ... basically, I need to know what type of SMSC connection you are using. Without that information, I can't provide much other troubleshooting guidance other than the above.

--
Des
NowSMS Support
William Law
New member
Username: Wlaww

Post Number: 2
Registered: 03-2009
Posted on Tuesday, April 07, 2009 - 10:10 pm:   

Hi,

The SMSC connection type is bluetooth modem. My cell phone, a Motorola V3, connects to a Bluetooth
adapter in my laptop and my Motorola V3 serves as a modem to send SMS out.

I have tested the long message. It does not work with a message longer than 160 characters. The phone cannot receive the long message.

I hope the above can help .

Thanks
William Law
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 672
Registered: 08-2008
Posted on Thursday, April 09, 2009 - 04:06 pm:   

Hi William,

In my experience, the GSM modem function in Motorola phones is broken and does not properly support sending binary messages.

They actually seem to have a problem sending any messages that include UDH ... User Data Header. UDH is where destination port information is encoded, as well as where segmentation information is recorded for long messages.

That said ... every Motorola phone that I've tested with will not send a message that includes UDH. They reject the message with "CMS ERROR: 304". It seems to be a bug unique to the Motorola phone modem implementation, as we haven't seen this problem in devices from any other manufacturer.

In your case, however, it sounds like the message is being sent, but it is somehow corrupted.

We can take a closer look at the SMSDEBUG.LOG to see how the modem is corrupting the message. But based on past experience, I expect that it is a dead end, and that Motorola still has a broken GSM modem implementation when it comes to sending SMS message that contain UDH.

I'd be curious to take a closer look at SMSDEBUG.LOG to see if there is a pattern to the way that the modem corrupts the message. However, I don't expect any miracle solutions ... the only real solution is a modem from a different manufacturer.

To enable the SMSDEBUG.LOG, there is a checkbox on the "Serial #" page of the NowSMS configuration dialog. Also make sure that you have "Receive SMS Messages" checked for the "Properties" of the modem in the "SMSC" list of NowSMS. Then try sending one of these messages that include destination port information back to the phone number of the modem itself. I'd be curious to see the SMSDEBUG.LOG showing the message being sent, and being received ... so that we can maybe see how the modem is corrupting the message. However, sadly this is just technical curiosity on my part, because I do not think there is anything we can do to fix it ... the Motorola modem implementation is what is broken.

--
Des
NowSMS Support
William Law
New member
Username: Wlaww

Post Number: 3
Registered: 03-2009
Posted on Friday, April 17, 2009 - 10:42 pm:   

The SMSDEBUG.LOG is attached
application/octet-streamSMSDEBUG.LOG
SMSDEBUG.LOG (28.2 k)
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 704
Registered: 08-2008
Posted on Monday, April 27, 2009 - 09:13 pm:   

Hi William,

That log shows the same "CMS ERROR: 304" that we see elsewhere.

Unfortunately the GSM modem implementation in most Motorola phones is simply broken. These modem implementations do not understand how to send any messages that include user data header (UDH), which is required for sending messages with port addressing, or for sending long messages.

Unless Motorola has released a new firmware update to fix this problem, there is no solution other than a different modem.

--
Des
NowSMS Support