Hi Serkan,
first of all, you shoul move towards 1.4.0 stable (1.4.1 stable is coming up), since it's more reliable and contains a lot of bug fixes, since 1.3.2 devel.
Serkan Camurcuoglu wrote:
Hi all,
We are using Kannel 1.3.2 at a site for handset access to content that's kept on a web server (Tomcat 4.1.29). The operating system is RedHat Linux Enterprise 3 (kernel 2.4.21-15.ELsmp). The handset is sent a wap service indication SMS containing the URL of the content to be downloaded. We use GPRS as the bearer. During the download of contents, we sometimes get the following errors:
WARNING: WSP: content-type <application/octet-stream> not supported
--> Is there any way (a configuration file or something) that I can make Kannel recognize the mime type application/octet-stream?
now, semantically this means: your HTTP server gives a HTTP response with content-type <application/octet-stream), _but_ the phone has not indicated (via Accept headers) that it accepts these media format. Hence check if your HTTP server is configured the "right way" to deliver the appropriate mime type. (Ie. your object is a midi, it should obviously be not application/octet-stream, but audio/midi.)
WARNING: WSP: Entity at http://192.168.210.201/icon_management/DownloadServlet/238/tYhthttxWY/Satisfaction.mid too large (size 84705 B, limit 65535 B)
--> How does Kannel decide the limit? It gives different values for different contents, such as 1400, 65535 or 10000 bytes. How can I change these settings?
now, the device has indicated a specific client SDU size limit. So obviously the device is not "capable" to handle a larger object. Can you please check wapbox.log in debug log-level to review what the WSP headers have been for this warning, and check if there is some kind of indication that the client has "limited" it's own capabilities.
Also I believe that the operator's GPRS network is slow, and there may be timeouts during the download process. What's the default timeout while waiting for an acknowledgement from the handset? Is it configurable?
can you point out for which timeouts this may be necessary? A snippet from the wapbox.log would be perfect to document the need.
I would really be grateful if someone could answer these questions as soon as possible.
as least with some delay, but hopefully "in time" ;)
Stipe
mailto:stolj_{at}_wapme.de ------------------------------------------------------------------- Wapme Systems AG
Vogelsanger Weg 80 40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0 fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de http://www.wapme-systems.de/ -------------------------------------------------------------------
