| What's the matter? |  Search
|
|
NowSMS Support Forums ⬆ MMS & SMS Technical Discussions (unsupported) ⬆ Archive through October 29, 2003 ⬆ |
◄ ► |
| Author | Message | |||
| newbie |
Hi, i write a WAP Session as following, wsp-connect:{ 0x0E,0x00,0x00,0x02,0x01,0x10,0x00,0x00 }; wsp-connectreply: { 12 80 00 02 8D 89 54 00 15 Encoding-version 1.2 00 } wsp-Post {0x0e,0x00,0x01,0x12,0x60,0x1c,0x02 POST / HTTP/1.1 \r\n Host: mmsc.newyok.tw:80 \r\n Content-Type: application/vnd.wap.mms-message\r\n Content-Length: 200 the following is m-send.req pdu.... 8c80981884022032....... } wsp-reply: { 12 80 01 04 63 59 03 94 81 84 92 04 3F 86 01 93 AB 48 54 54 50 2F 31 2E 31 20 68 74 74 70 70 72 6F,.... Your request for a service could not be fulfilled. Please try again or contact your operator if the problem persists } what's the meaning? what's wrong with the code? | |||
| Bryce Norwood - NowSMS Support |
Does your WSP Post actually include the literal text that you have included there??? You need to build a valid WSP POST PDU. You don't just stuff an HTTP header into the packet. HTTP headers get encoded using WSP header encoding. The URI gets its own field. | |||
| newbie |
Hi,bryce, thanks for your quick reply! Yes, my wsp-post ONLY include a string and I omit it here. I have build a wsp-post pdu, with a HTTP header and m_send.req( it begin with 8c80 above ), HTTP headers get encoded using WSP header encoding. The URI gets its own field. I don't understand it,could you explain it in detail? thanks a lot. is wsp-connectreply i got right? and you can give me a demo wsp-post pdu ? thanx again. | |||
| Bryce Norwood - NowSMS Support |
Take a look at this thread: http://support.nowsms.com/discus/messages/12/825.html "Transmit 3" is a WSP POST PDU. I don't know that it's 100% correct format, but it's definitely closer than what you have above. I'll get you started, but then you have to figure out the rest. 0A 7D AD 12 - This is the WTP header. It is a WTP invoke PDU. Refer to the Wireless Transaction Protocol (WTP) specification for information on how to decode this. 60 - This is the WSP PDU type field. Table 34 in the WSP spec, defines 60 as POST. Section 8.2.3.2 defines the POST PDU format. 17 - URI len 24 - headers len 68 - start of the URI ... Content-type is encoded as text "application/vnd.wap.mms-message". The remainder of the 0x24 bytes of header is 8080 8880. 80 80 - Accept: */* How do I know this? Well, I know that Table 39 tells me that the binary encoding of the "Accept:" header is 0. And while the WSP spec is not real clear on how 0x00 gets converted to 0x80, section 8.4.1.2 of WSP which defined "field value" encoding also applies to "field name" encoding. Then I find the content type encodings for the Accept header are defined in: http://www.wapforum.org/wina/wsp-content-type.htm Where 0 (mapped to 0x80 because of the rule cited above) is the content type "*/*". 88 80 translates to Cache-Control: No-cache I'd spend some time looking that PDU over, and studying the WSP spec, and make sure that you understand how I came up with what I described above. | |||
| newbie |
Hi,bryce, I use "0e,00,01,12" instead "0A 7D AD 12 "above, and other part is the same ,but I recv "18,00,01", why? where is my fault? | |||
| newbie |
on the other hand, I wonder if wsp-connectreply i get is right or not? thanks. | |||
| Anonymous |
Hi,I send a wsp-post package as following: and I get reply " Error Message format Corrupt",why? wsp-post { 0x0e,0x00,0x01,0x12,0x60,0x1c,0x24,0x68,0x74,0x74,0x70,0x3A,0x2F,0x2F,0x6D,0x6D, 0x73,0x63,0x2e,0x6d,0x6f,0x6e,0x74,0x65,0x72,0x6e,0x65,0x74,0x2e,0x63,0x6f,0x6d, 0x3a,0x38,0x30,0x61,0x70,0x70,0x6C,0x69,0x63,0x61,0x74,0x69,0x6F,0x6E,0x2F,0x76, 0x6E,0x64,0x2E,0x77,0x61,0x70,0x2E,0x6D,0x6D,0x73,0x2D,0x6D,0x65,0x73,0x73,0x61, 0x67,0x65,0x00,0x80,0x80,0x88, 0x80,0x8C,0x80,0x98,0x39,0x37,0x38,0x33,0x35,0x30,0x36,0x34,0x31,0x00,0x8D,0x90, 0x89,0x01,0x81,0x97,0x36,0x37,0x38,0x31,0x30,0x37,0x39,0x2F,0x54,0x59,0x50,0x45, 0x3D,0x50,0x4C,0x4D,0x4E,0x00,0x84,0xA3,0x01,0x04,0x05,0x03,0x83,0x81,0xEA,0x54, 0x65,0x73,0x74,0x20,0x85,0x85,0x85 } | |||
| Bryce Norwood - NowSMS Support |
I'm game to try to help you figure out what is wrong ... but I don't have a spare hour worth of time to manually decode your WSP POST PDU. How about if you reply back with details about how you think the PDU that you posted should be decoded. Then I'll validate your interpretation, and if there are errors, I'll try to point you to what does not look correct. | |||
| newbie |
1)after I Send wsp-Connect(0e,00,00,12,...) with ACK request,I get wsp-connectreply,with content" Encoding-version 1.2" wtp header is 12 80 00 02 2)then I send ACK to GW,and i get response: wtp header is 13 80,02 02, wsp is the same connectreply 3)send wsp-post to gw as above pdu, but I get reply " 13 80 01 ", ONLY three bytes, why? it is a ACK request PDU,not WSP-REPLY pdu. and tid is not order. why? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 910 Registered: 10-2002 |
I think there's a typo in your message .. in #2, the TID is "0002", which I don't think is correct. In your item #2, it looks like the GW is resending its response with the retry flag set, because it did not receive your ACK. If you get a reply of "13 80 01" in response to a WSP POST, that makes no sense. That is a WTP Result PDU header, not a WTP ACK PDU header. It is possible that you might receive a WTP ACK PDU before the WTP Result PDU. And why do you say the TID is not in order? Unless you're referring to #2, in which case maybe the gateway has a transaction left over for you from a previous session. | |||
| newbie Unregistered guest |
hi,bryce, I think TID order: is so: connect ( 00 00) connectreply ( 80 00) ack (00 00) Post (00,01) reply (80,01) ack (00,01) disconnect (00,02) right? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1003 Registered: 10-2002 |
That TID order looks right. The only consideration is that you *might* get an ACK back from the gateway before its reply or connectreply. connect ( 00 00) ack (80 00) - might be sent by gateway connectreply ( 80 00) ack (00 00) Post (00,01) ack (80 01) - might be sent by gateway reply (80,01) ack (00,01) disconnect (00,02) | |||
