The URL points to our webserver. So before I sent the SMS, I am closely watching the access log of our web server.
B) I can confirm that phone received the binary SMS, based on the fact that, the access log shows an IP address from the operator fetching the exact same URL that I specified in the OTA,
and the user-agent in the access log is empty ... and it only happens when I send the push OTA ... and the URL is quite new.
C) The Nokia 7650 gives a polymorphic ringtone ( saying there's a new message ) ... but nothing is in the Inbox.
Now my questions are:
A) The WSP Content Type in the push OTA SMS actually refers to an image/gif ( 0x80 | 0x1D ). The URL as well returns an image/gif. The GIF image I simply placed on the webserver.
Does the fact that the content-type is an image/gif and not an application/vnd.wap.mms-message ( 0x80 | 0x3E ), and the fact that the URL does not return an HTTP content-type of application/vnd.wap.mms-message
causes the phone / ( or the WAP gateway ) not to display the GIF? I can view the actual GIF via WAP by typing the URL on the phone.
In other words, must the Content-Type in the push OTA _and_ HTTP response header Content-Type always be application/vnd.wap.mms-message??
B) In order to serve MMS messages that are not stored on an operator's MMSC .... do I have to write a servlet that returns an HTTP body in WSP?
In other words, I cannot just use the normal HTTP responses but I have to perform binary-encoding ( as per WSP ) of the HTTP response headers ... and response body?
My understanding is that when the phone requests the URL containing the MMS... it goes through the WAP gateway ... and then the WAP gateway fetches the real URL on behalf of the phone ... much like a web proxy. I know that between WAP gateway and phone, it is basically WSP.
My question is, between WAP gateway and the website hosting the media, must the webserver also reply by WSP, and not your normal HTTP response headers and body?
I was also thinking of using Java servlets to do all of this, but if the HTTP response headers need to be binary-encoded ... but what can you do with HTTP response headers that are always there ( e.g.: like the "Server" response header telling the user-agent what kind of webserver is running in the case of iPlanet ) ... or HTTP response headers added by transparent proxies?
Must the HTTP response code ( HTTP/1.1 200 OK ) also be binary-encoded?