Thanks for decoding the OTA message, that kinda solved the case. It turned out that my content wasn't really formatted correctly (lesson learned: Java Strings aren't suitable for storing any binary data). I just managed to get a notification through to the phone (it informs that content is being fetched). I still can't se an actual fetch at out web server, but that's a completely other problem.
Regards, - Anders > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Aarno Syvänen > Sent: 10. heinäkuuta 2002 9:39 > To: [EMAIL PROTECTED] > Cc: 'Stipe Tolj'; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: m-notification-ind (cont.) > > > Anders Lindh kirjoittaa tiistaina, 9. heinäkuuta 2002, kello 18:14: > > I have a couple of questions regarding the tokenization, as I still > > haven't managed to get this working. > > > >> --asdlfjiuvwghasf > >> Content-Type: application/vnd.wap.mms-message > >> X-MMS-Message-Type: m-notification-ind > >> X-MMS-Transaction-Id: 125 > >> X-MMS-Version: 1.0 > >> X-MMS-Message-Class: personal > >> X-MMS-Message-Size: 100 > >> X-MMS-Expiry: 256; type=relative > >> X-MMS-Content-Location: your URI > >> --asdlfjiuvwghasf-- > > > > Should the encoded headers be posted to the PPG as mime encoded or > > not? In the example I've attached below, stuff isn't > submitted as mime > > encoded, which atleast looks ok. > > Note that Content-Type is application something, not text something. > This means > that it indeed must be binary. > > > > > > >> 84bc > > > > This is the content-type, so it should be last (7.0 in > > MMSEncapsulation). > > I think this one should be removed. It is MIME part > Content-Type, and it > is similar in all > MMS messages (even in notification having only headers !). Pi > should add > it. WAP-209, 7 refers, I think, to content type of MMS > message itself. > > > > >> 8c82 > >> 9831323500 > >> 8d90 > >> 8a80 > >> 8e0164 > >> 880481020100 > >> 83"yout URI"00 > > > > Anyway, here's my MMSEncapsulated doc: > > > 8c 82 > > // X-MMS-Message-Type: m-notification-ind > > 98 39 39 39 39 40 66 6c 79 65 72 6f 6e 65 2e 63 6f 6d 00 // > > X-MMS-Transaction-Id: [EMAIL PROTECTED] > > 8d 90 > > // X-MMS-Version: 1.0 > > 8a 80 > > // X-MMS-Message-Class: Personal > > 8e 01 64 > > // X-MMS-Size: 100 > > 88 06 80 04 3d 2b 32 4a > > // X-MMS-Expiry: an Absolute value, in the future > > 83 68 74 74 70 3a 2f 2f 77 77 77 2e 66 6c 79 65 72 6f 6e 65 > 2e 63 6f > > 6d 2f 00 // X-MMS-Content-Location: http://www.flyerone.com/ 84 be > > // Content-type: application/vnd.wap.mms-message > > OK, but see comment about Content-Type earlier > > > Text part: > > Is you got SI and SL right, then WSP headers should be OK (at > least for > SI and SL, that > is). But after that strange things appear. What is your transfer > encoding ? Is this the > message wapbox is sending to bearerbox. > > > 0f > Push Id > > 06 > PDU type: Push > > 0d > Headers part length, in octets (13) > > be > Content-Type: application/vnd.wap.mms-message > > 96 7f 00 a9 7f 00 > Host: localhost > > af 84 > X-WAP-Application-Id: mms.ua > > 8d c1 b4 80 > Content-Length: > > So following must be notification, Is this really binary encoded ? > > 3f 3f 3f 39 39 39 39 40 > > 66 6c 79 65 72 6f 6e 65 2e 63 6f 6d 00 3f 90 > > 3f 3f 3f 01 64 3f 06 3f 04 3d 2b 2f 4a 3f 68 74 74 70 3a 2f > 2f 77 77 > > 77 2e 66 6c 79 65 72 6f 6e 65 2e 63 6f 6d 2f 00 3f be > > > > udh: > > 06 05 04 0b 84 23 f0 > > I remember that got through SL and SI, so udh is at least right. > > > I haven't yet been able to decode this message, so I'd like some > > feedback if it even remotely looks like something that > could work, or > > if there's some obious flaw. > > You can try to send a direct binary to the phone. Only > mandatory header in WSP part is Content-Type, but now you > must add X-Wap-Application-Id, so that the right application > would handle the request. So add before the binary MMS notification: > > 0f 06 03 ce af 84 > > Aarno > >
