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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.