[Thomas]

Still no solution for the non-polling mode.

Switching to polling mode. It works at it should.

[Thomas]

The settings is as follows:

PDU mode: Enabled
ASCII 7-bit configuration: Charset = 3GPP 23.038
Ext. ASCII 8 bit conf: Nothing selected
Unicode conf: Nothing selected
HTTP API Configuration: Preferred Char Set: UTF-8

The recived XML states “ASCII” in the EncodingFlag field. This doesn’t change regardless of the Preferred Char Set in the HTTP API Configuration.

When sending a message from the iSms Webinterface to a mobile phone the SMS is recieved correctly.

When sending a message from the iSms Webinterface to the iSms the SMS is recieved correctly.

I think the issue is related to the iSms’s generation of the XML scheme/content in th API as the modem side seems to work correctly after the firmware update and with 3GPP.

Best regards

Thomas

[Thomas]

Hi,

The issue is solved with the solution provided, but the message is not send correctly to the Server default page when using the Non polling mode.

It seems that iSms is doing some kind to conversion before sending the XML to the non-polling page.

When sending a message like “æøå” the message looks o.k. when looking at it in the Inbox of the iSms. However when the XML is recieved on the server the Message has been transformed and the message looks like this: “���”

I have tried with “Preferred Character Set” set to “ISO-8859-1” and “UTF8”, but the result is the same. Actually the xml EncodingFlag is “ASCII” no mater the setting of “Preferred Character Set”.

When converting the recieved characters to bytes i get:

Using c# default encoding (ASCII): 65533;65533;65533;
Using c# UTF8 conversion: 239;191;189;239;191;189;239;191;189;

The current firmware is v1.51.21.

Do you have any solution for this issue or any suggestions?

Thanks

Thomas

[Author]

Posts