| Receiving WAP-Push, how to decode?? |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through September 15, 2003 ⬆ |
◄ ► |
| Author | Message | |||
| Christoph Zierl |
Hi, We have a project, where we have to receive wap-push messages over nowsms. When I receive such a message it is coded like this: 0605040B8423F0010601AE02056A0045C60C03636C69636B2E6578742E6E6F6B6961008503776572 6E657233372E636F643F7469643D3263363239636265373330363161613237373232316563363862 39373362633626743D31266C3D6465000AC3072003081112403110C3042003081601037765726E65 723337000101 Now I have to decode this message to get the WAP-URL out of it! I tried hex-->string convert, but it does not work. Does anyone know how to decode such a message, or is there any possibility in nowsms to get a wap-push in normal text format? thanks Christoph Zierl | |||
| Anonymous |
It's a WDp package co SMS, you can ref 23.040 and WDP Spec to decode it.06 mean the udh's length, 05, 04 mean following des port and orgport, 0b84 mean des port 2948, 23f0 means org port 9200, this is a connectionless wap push, it's in wdp package through sms. | |||
| Bryce Norwood - NowSMS Support |
Christoph, I don't have any good tools for decompiling a WBXML document (which is what you have here). The one reply talks about using the WDP spec as a starting point. That's a good starting point, but that will only explain the WDP header in the UDH of the message ... not the content itself. After the WDP header comes a WSP wrapper, and the content type (AE or 2E when you stip the high bit) is application/vnd.wap.sic, a WBXML encoding for a WAP service indication message. Looking at it from a quick and dirty perspective, it's a bit difficult to parse out the URL, because there are binary short cut encodings for "http://" and "http://www." so that a single binary token can take the place of either string. A simple parser could easily get confused. For the "application/vnd.wap.sic" content type (AE in the content-type field of the WSP header ... just beware that some apps might also include a character set parameter for the content type field, so if the first byte of the content-type field does not have the high bit set, this is a length field that tells you how long the content type field is that follows) ... You could do a simple quick and dirty parser that would work like this ... After you determine the content type is SI ... scan ahead to 45, which corresponds to an "<si>" tag that would start the WBXML document. Then go one byte at a time looking for 0B (href=), 0C (href=http://), 0D (href=http://www.), 0E (href=https://), 0F (href=https://www.). This should be followed by an 03 which indicates the start of a null terminated string. And you could get your URL this way ... Following this approach, in your example above, the URL is encoded starting with: 0C03636C69636B2E6578742E6E6F6B696100 There's only one problem ... The 00 null doesn't necessarily terminate the string. There are shortcut binary encodings defined for ".com/" (85), ".edu/" (86), ".net/" (87) and ".org/" (88). So after the null, you might see one of these values, which you do in your example. If so, append the appropriate text above. If the next character is an "03", then it indicates that another text string follows. Keep going until the character after the NULL is NOT one of the binary codings defined above, and is not "03". In your example, the complete URL encoding is contained within this segment: 0C03636C69636B2E6578742E6E6F6B6961008503776572 6E657233372E636F643F7469643D3263363239636265373330363161613237373232316563363862 39373362633626743D31266C3D6465000 Which I decode as 0C href=http:// 03636C69636B2E6578742E6E6F6B696100 click.ext.nokia 85 .com/ 03776572 6E657233372E636F643F7469643D3263363239636265373330363161613237373232316563363862 39373362633626743D31266C3D6465000 wer3? ... Well, I'll let you decode the rest. This would be for a very simple quick and dirty parse of an WAP push SI (Service indication) message. It's definitely not foolproof. Parsing the content type could be a bit tricky. One other thing that could cause a problem is if the WBXML document for the push used string table references for any part of the href URL. I would not expect that, but it is possible, and that would definitely throw you off. -bn | |||
