Re: m-notification-ind (cont.)
Aarno Syvänen <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <[email protected]> |
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