Voicemail Indicator DCS - 'Mostly' working, any suggestions welcome!

[dougforpres]

Hi,

Up until recently I have been using UDH info to control the Voicemail MWI on GSM CellPhones.
Of course, recently means just that - I was having difficulty with Windows Mobile based phones, they were not dealing very well with something in the message.  Some sources say it was the 8-bit encoding, others say WM powered phones don't like UDH.  I don't know, and I'm not getting much joy from Microsoft on this.

So... I decided to switch to sending messages encoded with the DCS of 0xC0 (1100-0000) and 0xC8 (1100-1000) to turn the Voicemail MWI OFF and ON respectively.  I am also including the 'ms_msg_wait_facilities' and 'ms_number_of_messages' TLV's.  According to the GSM spec DCS C0 & C8 are 'Discard' type messages.

From reading the SMPP spec I figured I'd need to set the sm_length to zero.

Tried that, SMPP gateway kicked me out (just dropped the connection), so I tried again, but this time added a 'message_payload' TLV with a content length of 0.  Now the gateway doesn't drop me, but fails to respond (and the message never gets sent)

This brings me to the meat of the matter - If I add some text to the message (so the gateway will accept it) the MWI on the phone does indeed switch on/off, but the text content gets stored as a TXT message, which must be deleted -- unacceptable to me and my customers.  I figure that some gateway along the path is seeing the text and OR'ing in the 'Store' bit (effectively converting the DCS to D0 or D8).

I have found that if I set the content to any SINGLE byte (doesn't really matter what the value is) then Nokia and Palm based devices (not checked others) drop the TXT and work ok... but the Windows phone goes and displays a 1-char TXT which must them be deleted.

First, an assumption:  I assume that the 'content' portion of the message (whether the 'short_message' field or the 'message_payload' TLV) must be missing when the encoded message finally makes it to the phone in order for the phone to behave correctly - correct me if I'm wrong on this.

Now, the question: Does the SMPP specification allow sending of 'null' messages... i.e. messages with a payload of 0 bytes?

I can provide hex dumps of the messages I am sending if that would assist.

Thanks in advance,
Doug

[SMS Forum Support]

SMPP does allow empty messages.. just set sm_length to 0 and do not append any extra octets. You could probably also get away with encoding a message_payload TLV with 0 length.

And I believe you are correct regarding MWI messages being empty.. I recall someone telling me this several years back that the messages should be empty.

Check that you are encoding nothing after the sm_length, not even a NULL and if that is the case, talk to the carrier/provider to determine why the connection misbehaves.

[dougforpres]

Thank you!

This is what I thought - I was actually sending a length of zero with no following bytes - that was the situation where the gateway was dropping me like a hot potato!  The gateway company said "SMPP does not allow for zero length messages" and that was that.  (that's when I tried adding the empty 'message_payload' TLV)

I eventually found a way around the particular problem with the Windows Mobile device and the MWI - Windows Mobile Devices do not support 8-bit encoding.... when I left the encoding for the UDH at 7-bit the phone started behaving correctly.

I'll go back to the gateway company and suggest they correct their software to support zero length messages - doubt I'll get very far with it.

Thank you again for your response - now all I need to do is find some kind soul to help me generate the correct PDU to get MWI working on a CDMA network - I'll post a request to the CDMA topic.

Doug