| MMS Message - How to build? |  Search
|
|
NowSMS Support Forums ⬆ MMS & SMS Technical Discussions (unsupported) ⬆ Archive through March 23, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| Anonymous |
Hi, I'm looking for a sample with explanation How to build MMS Message. I can't find anything usefull. I have created header part, text header part and I have added text data. But now I need to now how to build Image Header part. I have sample of Image header part, but I don't understand it. --------------------------- 8C 84 .... Message type - MMS Message 8D 90 .... MMS Version 85 04 .... datum and Lenght 3F 27 B3 43 .... datum value in sec from 01-01- 1970 84 A3 01 Content type (1 part - image or text only) - I don't understand what does A3 mean ---------------------------------------------- now starts Image Header: 1C 82 C6 1F ...this I don't understand I thing that there must be lenght and maybe size of the picture 9E C0 22 Content location or something like that  3C 31 32 ... <12 .... etc. Thanx Petr | |||
| Bryce Norwood - NowSMS Support |
Petr, A3 is the content type. MMS uses content type codes from the WAP WSP (Wireless Session Protocol) specification. Actually, the codes are published separately at http://www.wapforum.org/wina/wsp-content-type.htm. In this case, the content type is "application/vnd.wap.multipart.mixed", which has a code of 0x23 according to the WINA link, but WSP encoding OR's this value with 0x80. The content type field is ALWAYS the last field of the MMS header of an "m-retrieve-conf" (0x8C 0x84 header) or "m-send-req" format MMS message. Immediately after the content type field comes the content itself. In this case, you're looking at data encoded in the "application/vnd.wap.multipart.mixed" format. This format is defined in section 8.5 of the WAP WSP specification. Basically it is a binary encoding for a multipart MIME message. See this link here, as there's more discussion of this in another message: Explain MMS binary code -bn | |||
| Anonymous |
Thanx, I read that samples. Now I have specific problem. Octec 1C means the lenght of header (counted from 9E to the beginning of the Data). I found some examples of MMS's and I thing that the next 3 Octecs (82 C6 1F) means the lenght of te image file (jpeg). Because in another MMS, thare was only 2 octecs and these 2 Octecs were the same in two different MMS with the same image added (text message was different etc). But it is strange, that there was value 85 09 and the image was only 649B long. In another MMS, there was F0 09 and the image was 14KB long. Im confused of that. | |||
| Bryce Norwood - NowSMS Support |
Lengths are encoded as variable length unsigned integers, as defined by section 8.1.2 of the WAP Wireless Session Protocol (WSP) specification. Basically for each byte that has the high bit set, this indicates that the length continues for another byte. Your example of 82 C6 1F would decode to (0x02 * 0x80 + 0x46) * 0x80 + 0x1F = 0xA31F = 41759. 85 09 would decode to: 0x05 * 0x80 + 0x09 = 0x289 = 649. -bn | |||
| Anonymous |
Can you explain further about this decoding 85 09 would decode to: 0x05 * 0x80 + 0x09 = 0x289 = 649. logic. I read the WSP specification 8.1.2.. but could'nt understand! Perhaps a simpler explaination would be help ful. Also how can i get hex of the filesize e.g. i have file of 4123 bytes, how to reverse into hex.. Thanks! | |||
| Bryce Norwood - NowSMS Support |
Sure. If the high bit of one of the bytes in a length field is set (or with 0x80), then this indicates that the field continues for at least another byte. So you ignore this bit in computing the actual value. Let's take 85 09 ... In binary, this is: 10000101 00001001 (85 09) To decode this, you remove the high bit from each byte, which gives you this: 0000101 0001001 Or, converting the bits, to bytes, you get: 000010 10001001 02 89 And in decimal, 649. Does this explain it a bit more? | |||
| Anonymous |
I'm trying to learn about header encoding from WAP WSP spec... i'm a BEGINNER and i don't seem to understand quite a bit of what there. could you please suggest some useful sites where its explained in detail and in simple language? | |||
| Bryce Norwood - NowSMS Support |
Sorry, I don't know of any good resources. A copy of the relevant WAP/MMS specifications and a packet analyser like Ethereal is a good place to start. In fact, I wish I had a tool like Ethereal back when I was learning these protocols. | |||
| avi |
Hi, Is there a way to call the MMScomp utility not as an EXE but as a DLL function? or as a JAVA class? another question is, way does the mms notification refuses to send xx.mms files with content type "m-send-req" rather then "m-retrieve-conf" Thanks Avi | |||
| Bryce Norwood - NowSMS Support |
Hi Avi, No, the MMSCOMP utility only function as an EXE.
This is a very good question. I know this confuses a lot of people, and for very good reason. The reason that NowSMS refuses to generate an MMS notification for an m-send-req message is because a phone would not know what to do with an MMS message of that type. The basic flow is that an "m-notification-ind" message is sent to the phone. The phone issues a request to retrieve the message referenced in the notification, and it expects to receive an "m-retrieve-conf" message. (Refer to Section 6.3 of the WAP/OMA MMS Encapsulation Specification where this is specified.) So basically, if the phone retrieved an "m-send-req", that would be a protocol violation. The "m-send-req" format is what the phone generates when it wants to send a message. The initial releases of the Nokia MMSC use a variation of this phone-to-MMSC protocol ... basically they use the PDUs defined in the MMS Encapsulation Specification with some extra HTTP headers as defined in the Nokia EAIF specification. And for this reason, the Nokia Java libraries generate "m-send-req" format MMS messages ... in the format that they would be submitted to a Nokia MMSC via EAIF (or submitted by an MMS client using MM1). Just FYI ... the latest beta release (v5.0) of the Now SMS/MMS Gateway (http://www.nowsms.com/beta5) includes support for this EAIF interface, so if you wanted to use the Nokia libraries to submit mesages to the NowSMS gateway via EAIF, you could in this release. -bn | |||
| Anonymous |
Thanks Bryce! Now if you can explain me Also how can i get hex of the filesize e.g. i have file of 4123 bytes, how to reverse into hex.. ? | |||
| Anonymous |
Err! Sorry it was pretty simple! I figured it out no need to reply! Thanks once again Bryce! | |||
| Anonymous |
Hi I would like to know if an MMS notification can arrive as class 0 SMS? | |||
| Bryce Norwood - NowSMS Support |
The MMS notification message might be sent over SMS ... but the SMS headers will be stripped off of the message before it ever reaches the MMS client. So I would not expect the MMS client to have any knowledge of SMS headers or options. I'm guessing that you want to send an MMS message as a "flash" ... and I'm not aware of anyplace in the MMS specs where there is such an option. If you were to send the MMS notification message out as a "Class 0" message ... I'd also expect the behaviour to be undefined. That is to say, that some phones might see that it is a class 0 message, and try to display the content of the SMS message, never routing it to the MMS client. -bn | |||
| Anonymous |
mms version 0x90 how to explaint it? 100(0) the major version 4? 0000 the minor version 0 ok i duno the major version rite or not. thanks | |||
| Craig Dunn |
I have a question regarding this.... I'm trying to go the other way (to encode WSP Uintvar, rather than decode it.) - if you could help I'd be very grateful Bruce Wrote: >If the high bit of one of the bytes in a length >field is set (or with 0x80), then this indicates >that the field continues for at least another >byte. So you ignore this bit in computing the >actual value. That makes sense. >Let's take 85 09 ... >In binary, this is: >10000101 00001001 (85 09) So far so good.... >To decode this, you remove the high bit from each >byte, which gives you this: >0000101 0001001 Understood >Or, converting the bits, to bytes, you get: >000010 10001001 ^-^ ? Now - This is where I fall down - what method of computation is done to 'flip' the last bit of the first value to the next? >02 89 >And in decimal, 649. Going in reverse - Im taking 649 That is 1010001001 The hex for 649 is 02 89 So now I have 2 binary values 0000010 and 1011001 if I set the high contine bit, it should equal 10000010 01011001 This, as far as I can see is 130 89 - which encodes as 0x82 0x89 This is obviously wrong - since Im encoding 10000010 01011001 instead of 10000101 00001001 above - but I cant see what computation Im missing here. Thanks in advance for any help Cheers. Craig | |||
| Bryce Norwood - NowSMS Support |
Section 7.2.18 of the MMS Encapsulation Specification, published by the Open Mobile Alliance covers this. Basically, the version number is encoded as a WSP short integer, which is a 7 bit value. The three most significant bits (001) are used to encode a major version number in the range 1-7. The four least significant bits (0000) contain a minor version number in the range 1-14. So for v1.0, that is encoded in binary as 0010000. Now we have to encode that value using the WSP "short-integer" format. Section 8.4.2.1 of the Wireless Session Protocol specification, published by the Open Mobile Alliance defines this:
So now we get 10010000 in binary, or 0x90. | |||
| Bryce Norwood - NowSMS Support |
Craig, Based upon another post, I think you got things sorted, but I wanted to provide a follow-up explanation here for the following:
Basically, here I had two 7 bit values: 0000101 0001001 But if I want to decode the value in a standard number format, I need to look at it differently. If I remove the separation between the bytes, I see a binary number value as follows: 00001010001001 (All I've done is remove the space here, as that is was really just there for formatting.) Now, I want to convert this binary format to a hex format. 000010 10001001 So I separate off the lower 8 bits, and basically I'm just changing where the space character is, so that I can more easily convert this into the hex value: 02 89 Or 0289 ... which then translates to 649 decimal. I probably wouldn't make a very good instructor explaining in how I explain this process, but it should now make sense. -bn | |||
| Dilshod New member Username: Dilnab Post Number: 1 Registered: 11-2003 |
Hi all, That is a good discussion, it helps me. But aniway i have a questions. 1. I use visual C++ to send M-Send.req. For this i create soket with connectionless port 9200. I create PDU like described in WAP-230 pdu[0] = 0x01; //TID pdu[1] = 0x60; //Post by table 34 of Doc pdu[2] = 0x60; //Length of MMSC URL pdu[3] = 0x68; //http://....... MMSC URL pdu[4] = 0x74; pdu[5] = 0x74; pdu[6] = 0x70; pdu[7] = 0x3a; pdu[8] = 0x2f; pdu[9] = 0x2f; .............. pdu[14] = 0x3e; //aplication/vnd.wap.mms-message Is that correct? Can somebody explayn me how to create PDU from very begining (not only from MMS header). Some sample of PDU dump. 2. In document WAP-209 structure of MMS send request. In some sample dump i found that every fields have they code for example X-Mms-Message-Type - 8Ch X-Mms-Transaction-ID - 98h X-Mms-MMS-Version - 8Dh From - 89h ... Is that correct and what document has a full table of codes? X-Mms-Message-Type value of m-send-req is 80h is that correct? Where i can find the values of other typesm-send-conf,m-retrieve-conf? Thanks Where is the document | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1119 Registered: 10-2002 |
1.) If your message is small, then you could probably get away with a connection-less WSP request. But every MMS client that I have seen uses connection-oriented WSP (and segmentation-and-reassembly at the WTP layer for larger messages). Regarding your PDU, see Section 8.2.3.2 of the WAP WSP specification (WAP-230 as you reference). pdu[2] would indeed be UriLen, but pdu[3] would be HeadersLen. Then comes the URI itself. When you get down to the Content-type field, while 3E is the correct content type code for "application/vnd.wap.mms-message", you would encode it as BE. Why? See Section 8.4.2.24 for the defintion of content type encoding. You are using "constrained-media" encoding, which Section 8.4.2.7 equates to "constrained-encoding". Section 8.4.2.1 defines this as either "Extension-media", which is a text string, or a "Short-integer" value (which is a value in the range 0-127 that gets encoded with the high bit set, hence 3E becomes BE). FWIW, for compatibility with older systems, almost every MMS client that I have seen uses the text content type encoding "application/vnd.wap.mms-message" followed by NULL as the content type, instead of using the content type code, although both encodings are legal. 2.) Keep reading WAP-209 (MMS Encapsulation Specification), as the codes are in there. Section 7.3 has the assigned numbers. Because WSP encoding is used (see Section 8.4.1 of WSP specification), note that the high bit is set in the header field encoding, so Message-Type is defined in the table as having a value of 0x0C. But when you use it as a header field encoding, it becomes 0x8C. Section 7.2 has the encoding values for header values. You'll find m-send-req, m-send-conf, and m-retrieve-conf all defined under Section 7.2.14. -bn | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1120 Registered: 10-2002 |
For an example of a PDU dump, I'll provide the following. I leave it to others to annotate, and I'll answer any specific questions on it. (My philosophy is that you learn better if you at least try to work through it yourself.) Send: 0A 00 03 12 01 10 0A 3D 04 80 8F F8 00 04 81 8F // = F8 00 A9 4E 6F 77 20 53 4D 53 2F 4D 4D 53 20 47 // Now SMS/MMS G 61 74 65 77 61 79 20 76 35 2E 30 00 80 83 80 61 //ateway v5.0 a 70 70 6C 69 63 61 74 69 6F 6E 2F 76 6E 64 2E 77 //pplication/vnd.w 61 70 2E 6D 6D 73 2D 6D 65 73 73 61 67 65 00 //ap.mms-message Receive: 12 80 03 02 9C 82 6A 00 15 45 6E 63 6F 64 69 6E // j Encodin 67 2D 76 65 72 73 69 6F 6E 00 31 2E 32 00 //g-version 1.2 Send: 18 00 03 Send: 0A 00 04 12 60 22 43 68 74 74 70 3A 2F 2F 32 31 // `"Chttp://21 36 2E 31 35 35 2E 31 37 34 2E 38 34 2F 73 65 72 //6.155.174.84/ser 76 6C 65 74 73 2F 6D 6D 73 61 70 70 6C 69 63 61 //vlets/mmsapplica 74 69 6F 6E 2F 76 6E 64 2E 77 61 70 2E 6D 6D 73 //tion/vnd.wap.mms 2D 6D 65 73 73 61 67 65 00 80 61 70 70 6C 69 63 //-message applic 61 74 69 6F 6E 2F 76 6E 64 2E 77 61 70 2E 6D 6D //ation/vnd.wap.mm 73 2D 6D 65 73 73 61 67 65 00 88 80 8C 80 98 31 //s-message 1 39 31 38 32 43 45 38 00 8D 90 89 01 81 97 2B 31 //9182CE8 +1 39 39 39 35 35 35 31 32 31 30 2F 54 59 50 45 3D //9995551210/TYPE= 50 4C 4D 4E 00 96 2B 31 39 39 39 35 35 35 31 32 //PLMN +199955512 31 30 00 86 81 84 A3 02 20 10 83 C0 22 3C 33 46 //10 "<3F 42 33 45 30 41 42 2E 74 78 74 3E 00 8E 33 46 42 //B3E0AB.txt> 3FB 33 45 30 41 42 2E 74 78 74 00 53 69 6D 70 6C 65 //3E0AB.txt Simple 20 74 65 73 74 20 4D 4D 53 2E 16 86 66 9D C0 22 // test MMS. f " 3C 35 38 31 2E 67 69 66 3E 00 8E 35 38 31 2E 67 //<581.gif> 581.g 69 66 00 47 49 46 38 39 61 64 00 32 00 B3 00 00 //if GIF89ad 2 00 00 00 33 33 00 66 66 33 99 99 00 CC CC 00 CC // 33 ff3 CC 66 CC CC 99 FF CC 00 FF FF FF FF FF FF 00 00 // f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // 21 F9 04 01 00 00 09 00 2C 00 00 00 00 64 00 32 //! , d 2 00 00 04 FE 30 C9 49 2B 35 A5 9C CD 4F 31 86 25 // 0 I+5 O1 % 8E A4 85 69 DD F6 85 65 EB 26 58 2A 77 DF 6B 4F // i e &X*w kO F1 3C D7 B7 6D E8 40 0E AF 37 FA 05 81 43 A2 E9 // < m @ 7 C 28 10 10 82 05 65 C5 08 6C 3E 91 D2 0A AA 0A 00 //( e l> 04 AE 58 E9 56 27 E8 7E 8F 51 29 15 48 E8 76 05 // X V' ~ Q) H v 47 0F 71 AD 6B BB E1 68 25 9D EC F6 82 91 2C 2E //G q k h% ,. 7B 33 65 6E 67 68 81 82 71 1B 01 7D 00 7F 80 8A // 3engh q 8B 8D 7D 90 3A 49 24 83 04 4E 1D 04 94 6E 03 29 // :I$ N n ) 03 A1 32 69 99 33 9B 7F 9E 8E A4 1C A3 3B 92 29 // 2i 3 ; ) 76 8F AE 8E 00 78 1B 85 B8 1D 89 53 A8 6E 60 03 //v x S n` B6 BB BA 33 BD 16 63 1C 9F 01 B5 8E B8 C2 C0 C6 // 3 c 23 C9 8C 86 CD 7D CF 95 D2 45 BF 7D A4 D0 D8 CA //# E E1 33 22 9A AC 1B E0 77 E2 EA E4 E5 7C E3 E9 6F // 3" w | o 1B B3 66 3A BD 83 07 85 EC F1 B7 F3 8E CC DB B4 // f: E8 18 E6 EF DC 01 7E 96 36 08 9C 41 F0 00 BD 2E // ~ 6 A . DF 6C 25 3C B0 A4 DB B8 7C 8E AE E8 03 75 09 47 // l%< | u G 9D 86 FE 18 B5 85 F4 D6 91 02 B5 82 17 37 02 1C // 7 C9 51 C7 84 93 0E 41 AA E4 B0 11 22 90 85 32 1E // Q A " 2 F6 43 B9 93 A5 4D 7B 12 60 EA C4 45 0F 57 4D 00 // C M ` E WM AD 64 04 C2 17 D3 59 87 42 87 7C 22 C5 C2 74 E8 // d Y B |" t 53 33 60 8E 26 4D 61 8A E9 01 90 B9 04 24 45 18 //S3` &Ma $E 04 46 10 B0 F9 C4 76 20 7B 33 68 90 9A 5B 2D BA // F v 3h [- 39 92 E3 5D CB 20 3A E9 BA 05 12 6F 62 8A 99 8B //9 ] : ob F8 66 5C 04 18 08 8B 23 45 FD 5E BD 1B 38 27 36 // f\ #E ^ 8'6 C5 34 49 06 39 7C 04 9A DA 45 AB BC 34 0E 62 39 // 4I 9| E 4 b9 6E 1D 4A 2B C3 10 6E B2 79 80 80 A8 9B 09 91 6E //n J+ n y n 6C 1A 75 DB D4 B0 63 CB 9E CD 41 02 ED DB B8 73 //l u c A s 77 B0 AD BB B7 EF CD BC 7F 0B 1F CE 35 38 F1 E3 //w 58 BF D3 C0 44 CE 3C B6 72 54 56 70 13 18 00 19 3A // D < rTVp : A7 DB D3 FD B2 A0 D3 FA 27 6D 3B 01 AE F3 92 D1 // 'm; 7D 2A 76 33 E2 39 6C EF B0 CC 73 EC 8D BB A2 AC // *v3 9l s 69 AF 1B 3E 0D 93 34 C3 F7 CC AD 2F F4 F3 5C FA //i > 4 / \ ED FE 82 5B 7F F7 BD 24 4B 17 D5 35 D6 48 7A 07 // [ $K 5 Hz B0 90 8C 1D 09 06 B6 20 24 89 EC B1 A0 6E D0 58 // $ n X E2 51 0A 17 E6 96 A1 0C C8 88 E2 DD 6C 76 08 D8 // Q lv 20 7E 6B 8D 28 5B 89 4A 55 C4 C1 2C 11 02 41 09 // ~k ([ JU , A 24 A6 48 40 07 8C B7 CD 58 9C 08 C9 40 15 A3 0C //$ H@ X @ 94 98 78 4C 8F 58 CD 16 64 8B E5 8C 91 99 6B 12 // xL X d k CE B5 E3 14 4A 82 F6 E3 3A 00 94 52 02 77 92 05 // J : R w 96 99 79 BB 71 93 22 63 71 6C 19 57 2C E8 F4 11 // y q "cql W, 80 7B 9D D8 97 C2 31 17 88 68 08 9A 2F AA C9 CB // 1 h / 0B 44 9A E9 04 24 D3 D5 24 A4 0B 75 1A 72 A7 2C // D $ $ u r , A6 39 B5 E6 0D C9 F0 F3 46 13 4D D8 C2 A5 7A 36 // 9 F M z6 14 AA E8 2D 88 1E B5 E8 06 6C 96 F0 E0 27 8F FE // - l ' 63 49 A5 D3 C8 82 69 A6 86 6C AA 46 A1 9F 2A 7A //cI i l F *z 66 40 37 D4 85 4E A9 B6 9C 8A E4 A8 39 35 11 C0 //f@7 N 95 AC B4 8A 95 50 8D 73 50 B3 C9 69 B4 CE 6A 2B 2C // P sP i j+, 59 5C B0 5C 1C 98 C0 2A 5B B1 C1 C2 90 C1 66 C8 //Y\ \ *[ f 16 06 7B 02 B3 9C 26 6B 63 06 30 65 10 AD B4 CA // &kc 0e 2E BB 43 B3 25 44 00 00 3B //. C %D ; Receive: 12 80 04 04 20 81 07 61 70 70 6C 69 63 61 74 69 // applicati 6F 6E 2F 76 6E 64 2E 77 61 70 2E 6D 6D 73 2D 6D //on/vnd.wap.mms-m 65 73 73 61 67 65 00 92 04 3F B3 E0 6A A6 52 65 //essage ? j Re 73 69 6E 2F 32 2E 31 2E 36 00 58 2D 4D 6F 61 2D //sin/2.1.6 X-Moa- 70 72 6F 63 65 73 73 65 64 00 31 2E 32 33 00 85 //processed 1.23 81 AB 48 54 54 50 2F 31 2E 31 20 70 72 6F 65 64 // HTTP/1.1 proed 77 6D 70 78 79 30 31 20 28 54 72 61 66 66 69 63 //wmpxy01 (Traffic 2D 53 65 72 76 65 72 2F 35 2E 31 2E 33 2D 35 35 //-Server/5.1.3-55 35 39 30 20 5B 63 4D 73 53 66 20 5D 29 00 8C 81 //590 [cMsSf ]) 98 31 39 31 38 32 43 45 38 00 8D 90 92 80 8B 31 // 19182CE8 1 32 38 38 33 33 38 32 40 74 6D 6F 6D 61 69 6C 2E //2883382@tmomail. 6E 65 74 00 //net Send: 18 00 04 Send: 0A 00 05 12 05 9C 82 6A // j | |||
| Dilshod New member Username: Dilnab Post Number: 2 Registered: 11-2003 |
That's good I undestand many things but aniway there are questions. -------------------------------- >Send: >0A 00 03 12 01 10 0A 3D 04 80 8F F8 00 04 81 8F // = >F8 00 A9 4E 6F 77 20 53 4D 53 2F 4D 4D 53 20 47 // Now SMS/MMS G >61 74 65 77 61 79 20 76 35 2E 30 00 80 83 80 61 //ateway v5.0 a >70 70 6C 69 63 61 74 69 6F 6E 2F 76 6E 64 2E 77 //pplication/vnd.w >61 70 2E 6D 6D 73 2D 6D 65 73 73 61 67 65 00 //ap.mms-message 1 byte 0A = 0000 1010 - Invoke PDU Type I think 00 03 is TID 5 byte 01 - Connect type This is maybe S-Connect.req, isn't it? So 10 is version, 0A capabilities len, 3D headers len, then 10 bytes of capabilities an 61 bytes of headers. Is that right? -------------------------------- >Receive: >12 80 03 02 9C 82 6A 00 15 45 6E 63 6F 64 69 6E // j Encodin >67 2D 76 65 72 73 69 6F 6E 00 31 2E 32 00 //g-version 1.2 1 byte 12 = 0001 0010 - Result PDU type As described this maybe connect reply PDU so 80 03 is Server session ID = 3, 02 - capabilities LEn, 9C 82 6A headers len so as you explaned it will calculates as (1C*80+2)*80+6A=7016A=459114 bytes!!! There is no such amount of bytes where is my fault? -------------------------------- >Send: >18 00 03 1 byte 18 = 0001 1000 - Ack PDU type I think 00 03 is TID What PDU is this? What section in WAP-230 describes this? -------------------------------- >Send: >0A 00 04 12 60 22 43 68 74 74 70 3A 2F 2F 32 31 // `"Chttp://21 >36 2E 31 35 35 2E 31 37 34 2E 38 34 2F 73 65 72 //6.155.174.84/ser >76 6C 65 74 73 2F 6D 6D 73 61 70 70 6C 69 63 61 //vlets/mmsapplica >74 69 6F 6E 2F 76 6E 64 2E 77 61 70 2E 6D 6D 73 //tion/vnd.wap.mms >2D 6D 65 73 73 61 67 65 00 80 61 70 70 6C 69 63 //-message applic >61 74 69 6F 6E 2F 76 6E 64 2E 77 61 70 2E 6D 6D //ation/vnd.wap.mm >73 2D 6D 65 73 73 61 67 65 00 88 80 8C 80 98 31 //s-message 1 >39 31 38 32 43 45 38 00 8D 90 89 01 81 97 2B 31 //9182CE8 +1 >39 39 39 35 35 35 31 32 31 30 2F 54 59 50 45 3D //9995551210/TYPE= >50 4C 4D 4E 00 96 2B 31 39 39 39 35 35 35 31 32 //PLMN +199955512 >31 30 00 86 81 84 A3 02 20 10 83 C0 22 3C 33 46 //10 "<3F >42 33 45 30 41 42 2E 74 78 74 3E 00 8E 33 46 42 //B3E0AB.txt> 3FB >33 45 30 41 42 2E 74 78 74 00 53 69 6D 70 6C 65 //3E0AB.txt Simple >20 74 65 73 74 20 4D 4D 53 2E 16 86 66 9D C0 22 // test MMS. f " >3C 35 38 31 2E 67 69 66 3E 00 8E 35 38 31 2E 67 //<581.gif> 581.g >69 66 00 47 49 46 38 39 61 64 00 32 00 B3 00 00 //if GIF89ad 2 >00 00 00 33 33 00 66 66 33 99 99 00 CC CC 00 CC // 33 ff3 >CC 66 CC CC 99 FF CC 00 FF FF FF FF FF FF 00 00 // f >00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // >21 F9 04 01 00 00 09 00 2C 00 00 00 00 64 00 32 //! , d 2 >00 00 04 FE 30 C9 49 2B 35 A5 9C CD 4F 31 86 25 // 0 I+5 O1 % >8E A4 85 69 DD F6 85 65 EB 26 58 2A 77 DF 6B 4F // i e &X*w kO >F1 3C D7 B7 6D E8 40 0E AF 37 FA 05 81 43 A2 E9 // < m @ 7 C >28 10 10 82 05 65 C5 08 6C 3E 91 D2 0A AA 0A 00 //( e l> ................................................................. >66 40 37 D4 85 4E A9 B6 9C 8A E4 A8 39 35 11 C0 //f@7 N 95 >AC B4 8A 95 50 8D 73 50 B3 C9 69 B4 CE 6A 2B 2C // P sP i j+, >59 5C B0 5C 1C 98 C0 2A 5B B1 C1 C2 90 C1 66 C8 //Y\ \ *[ f >16 06 7B 02 B3 9C 26 6B 63 06 30 65 10 AD B4 CA // &kc 0e >2E BB 43 B3 25 44 00 00 3B //. C %D ; 1 byte 0A = 0000 1010 - Invoke PDU Type 00 04 - TID 5 byte 60 - Post type 6 byte 22 - URI length 34 bytes - http://216.155.174.84/servlets/mms 7 byte 43 - Headers Len - 67 bytes 61 70 70 6C 69 63 61 //vlets/mmsapplica 74 69 6F 6E 2F 76 6E 64 2E 77 61 70 2E 6D 6D 73 //tion/vnd.wap.mms 2D 6D 65 73 73 61 67 65 00 80 61 70 70 6C 69 63 //-message applic 61 74 69 6F 6E 2F 76 6E 64 2E 77 61 70 2E 6D 6D //ation/vnd.wap.mm 73 2D 6D 65 73 73 61 67 65 00 88 80 Is that correct? -------------------------------- >Receive: >12 80 04 04 20 81 07 61 70 70 6C 69 63 61 74 69 // applicati >6F 6E 2F 76 6E 64 2E 77 61 70 2E 6D 6D 73 2D 6D //on/vnd.wap.mms-m >65 73 73 61 67 65 00 92 04 3F B3 E0 6A A6 52 65 //essage ? j Re >73 69 6E 2F 32 2E 31 2E 36 00 58 2D 4D 6F 61 2D //sin/2.1.6 X-Moa- >70 72 6F 63 65 73 73 65 64 00 31 2E 32 33 00 85 //processed 1.23 >81 AB 48 54 54 50 2F 31 2E 31 20 70 72 6F 65 64 // HTTP/1.1 proed >77 6D 70 78 79 30 31 20 28 54 72 61 66 66 69 63 //wmpxy01 (Traffic >2D 53 65 72 76 65 72 2F 35 2E 31 2E 33 2D 35 35 //-Server/5.1.3-55 >35 39 30 20 5B 63 4D 73 53 66 20 5D 29 00 8C 81 //590 [cMsSf ]) >98 31 39 31 38 32 43 45 38 00 8D 90 92 80 8B 31 // 19182CE8 1 >32 38 38 33 33 38 32 40 74 6D 6F 6D 61 69 6C 2E //2883382@tmomail. >6E 65 74 00 //net 1 byte 12 = 0001 0010 - Result PDU type 80 04 - Status = 4 04 - Headers Len Please help me how can i find parts of this PDU (content type, headers, data...) I don't understand the syntaksys described in 8.4.2.24 Content-type-value = constrained media|Content-general-form ..... Just can you show me where begins and ends this field. -------------------------------- >Send: >18 00 04 1 byte 18 = 0001 1000 - Ack PDU type I think 00 04 is TID What PDU is this? What section in WAP-230 describes this? -------------------------------- >Send: >0A 00 05 12 05 9C 82 6A // j 1 byte 0A = 0000 1010 - Invoke PDU Type I think 00 05 is TID 5 byte 05 - Disconnect PDU type Thanks | |||
| Emanuele Vittore New member Username: Emavit Post Number: 18 Registered: 10-2003 |
Is this Exact? This byte i must send to Wap Gateway ? THANK YOU VARY VARY | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1162 Registered: 10-2002 |
This is a transaction sequence of an actual live sending of an MMS message through a WAP gateway (I only modified the phone number in the request to a phony phone number). You would need to modify it for actually sending to your operator's MMSC (the URL in the WSP POST transaction, which is the 2nd packet sent), and you would need to modify the MMS content (also part of this WSP POST) to send the message that you want to send. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1163 Registered: 10-2002 |
Correct.
The WTP Invoke PDU header is usually 4 bytes (unless TPIs are present), and the WTP Result PDU is usually 3 bytes. So the 4th byte, 02 is the WSP PDU type, where 02 is ConnectReply. The server session id is 9C 82 6A.
This is a WTP layer acknowledgement. WTP is defined in WAP-224. This is to acknowledge receipt of the previous response, otherwise the server will continue to retry the response. Your WSP Post interpretation appears correct. On the subsequent receive, again, you have a 3 byte WTP header, and then the WSP Reply PDU follows.
Content-type is one of the messiest headers. In this case, we have a very simple one. The null terminated string "application/vnd.wap.mms-message" is the content type header. Here are some general rules for parsing the content-type header field:
And you'll notice that this PDU includes 9C 82 6A, which is the server session ID returned in the earlier ConnectReply. | |||
| Marty New member Username: Marty Post Number: 21 Registered: 10-2003 |
What I am confused about is the first octet of every PDU. I think it is a little detail that I've forgotten but I don't know why 0x0A = Invoke PDU. If you take a look at WAP-224: 8.3.1, if CON = 0, then PDU Type = 101 which is Segmented Invoke and not normal Invoke which is 001. And shouldn't there be 4 octets instead of 3 for the Invoke PDU? The result PDU type starts with 0x12, what does this mean? Can I see information about SAR in these dumps or isn't there SAR used. Why does the TID srart at '03', is the first part of the session not shown? | |||
| Dilshod New member Username: Dilnab Post Number: 3 Registered: 11-2003 |
Thank you very much Bryce Norwood, many things become clear to me. Marty, i think this doc (WAP-224-WTP 8.1 General) helps you. 0x0A = 0000 1010, so bit 1-4(first=0)=0001=0x01-Invoke PDU type | |||
| Marty New member Username: Marty Post Number: 22 Registered: 10-2003 |
Thanks Dilshod How silly of me, I wasn't reading it the right way. I am used to start reading at the LSB. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1204 Registered: 10-2002 |
Let me see if I can find a simple log that includes a SAR transaction. As for the TID starting at 03 ... the particular app that I grabbed this from just keeps incrementing TID, so there was a previous connect/disconnect that the client had issued. It could reset the TID back to 01 ... but most clients don't. | |||
| Dilshod New member Username: Dilnab Post Number: 4 Registered: 11-2003 |
In connection mode m-send-conf MMS proxy-relay sends to MS in the same session( as in sample dump). But in connectionless mode MMS proxy-relay uses PUSH method to send m-send-conf to MS. Is it correct? | |||
| Paul Richardson New member Username: Paulr Post Number: 1 Registered: 11-2003 |
Hi Bryce. I have been following this thread and I would be really interested to see a SAR transaction if you have one. I have a situation where our client in certain parts of the world is able to send large MMS's but is restricted to 1K in other parts. I have seen a reply from you to a member mentioning that gateways have certain limits, which could cause the problem I am seeing. I haven't as yet been able to get any logs of the UDP packet exchange when my client sees the error, but I am working on it. I know I am rambling a bit here, but what I would like to know is would I be able to see in the connect reply from the server if SAR is supported. Just one more thing for now. In the example log you have posted here the connect Send: 0A 00 03 12 01 10 0A 3D 04 80 8F F8 00 04 81 8F // = F8 00 A9 4E 6F 77 20 53 4D 53 2F 4D 4D 53 20 47 // Now SMS/MMS G 61 74 65 77 61 79 20 76 35 2E 30 00 80 83 80 61 //ateway v5.0 a 70 70 6C 69 63 61 74 69 6F 6E 2F 76 6E 64 2E 77 //pplication/vnd.w 61 70 2E 6D 6D 73 2D 6D 65 73 73 61 67 65 00 //ap.mms-message Is this then saying that the max SDU is 8F,F8,00 and if so what does this calculate to. Thanks for any help. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1237 Registered: 10-2002 |
No. The M-send.conf is a direct response to the M-send.req. From the perspective of the MMSC, the MMSC receives M-send.req as an HTTP POST. The MMSC generates an M-send.conf as the response to that HTTP POST. If this transaction is occurring through a WAP proxy, the M-send.req is a WSP POST, and the M-send.conf is the reply (WSP reply PDU) to that request. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1238 Registered: 10-2002 |
Unfortunately, due to my schedule, it may be a week or two before I have time to produce another log. But the short of it ... The GTR and TTR flags of the WTP header are what should be used to convey this. If a client supports SAR, then it should never set both of these flags. (See WTP spec, section 8.2.2.) If the server supports SAR, then the same goes for it. (For a simple single packet response, the TTR flag gets set, and the GTR is clear.) (Note: Some servers will only respond indicating that they support SAR if the client request indicated that it supported SAR.)
It's another uintvar value. Section 8.1.2 of the WSP spec has a good description of decoding. But here's how I decode it when I decode it manually ... 8F F8 00 Convert to binary 10001111 11111000 00000000 Strip the high bit of each word 0001111 1111000 0000000 Push bits to the right to re-align on byte/word boundaries 00011 11111100 00000000 Convert back to hex 03 FC 00 Convert to decimal 261120 It's a little tough to explain this way, but hopefully that will make some sense. | |||
| Anonymous |
Hey Bryce, Fascinating discussion. How is the binary data actually sent to the MMSC - is this just sending the binary data over a TCP/IP connection to the specified port - i.e. is the protocol similar to that of SMPP (ack/res) in terms of sending/receiving data over a direct connection (connectionless over port 9200)? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1281 Registered: 10-2002 |
An MMSC accepts HTTP connections. Submitting an MMS message to an MMSC is logically an HTTP POST. Most MMS client implementations, however, do this over a WAP proxy (WAP gateway), where WAP protocols are used instead. The WAP protocols in this case are binary encodings of the equivalent HTTP transaction (HTTP headers are binary encoded to conserve space), with the transactions occurring over UDP instead of TCP/IP. | |||
| Dilshod New member Username: Dilnab Post Number: 5 Registered: 11-2003 |
Hi, when sending to WAP gate: 0x0A, //0a=0000 1010 - Invoke WTP PDU type 0x00, //TID 0x03, //TID 0x12, // 0x01, //Connect WSP PDU type S-Conect.req 0x10, //WAP version 0x13, //Capability len 0x3D, //Headers len .... received: 0x21 - 0010 0001 - This is Abort PDU type 0x80 - TID 0x03 - TID 0xE0 what is the reason of abort - 0xE0 thanks | |||
| kevin New member Username: Kevin Post Number: 6 Registered: 10-2003 |
Hi; In your message: 84 A3 02 20 10 83 C0 22 3C 33 46 42 33 45 30 41 42 2E 74 78 74 3E 00 8E 33 46 42 84: Content-type A3:application/vnd.wap.multipart.mixed But what the meaning of 02 20 10 83 C0 22 3C 33 46? thank you in advanced! | |||
| Dilshod New member Username: Dilnab Post Number: 6 Registered: 11-2003 |
Hi Bryce, can you send example of a PDU dump for WTLS connection (port 9203) Thanks | |||
| Emanuele Vittore New member Username: Emavit Post Number: 20 Registered: 10-2003 |
Hi Bryce , my gateway simulator when i send connect and post, it send me with : 1C ?? I don't Know 80 TID 02 TID Thanks | |||
| yanxh New member Username: Yanxh Post Number: 7 Registered: 11-2003 |
Hi,Emanuele, 1c is Redirect pdu, see wap-230 for more details. which maybe tell you the GW has changed the address. | |||
| yanxh New member Username: Yanxh Post Number: 8 Registered: 11-2003 |
Hi,kevin I think you should read multipart in wap-230. entries number| headerlen|datalen|content-type|header|data| well, the following is the explaination for it: 02 ---- entries number: 2 files 20 ---- header len : 32 bytes 10 ---- data len :16 bytes 83 ---- content-type:texp/plain C0 22 3C 33 46 42 33 45 30 41 42 2E 74 78 74 3E 00 ---- Content-ID:<3FB3E0AB.txt> 8E 33 46 42 33 45 30 41 42 2E 74 78 74 00 ---- Content-Location:3FB3E0AB.txt | |||
| Dilshod New member Username: Dilnab Post Number: 7 Registered: 11-2003 |
Hi,yanxh >1c is Redirect pdu, see wap-230 for more details. >which maybe tell you the GW has changed the address 1C ?? I don't Know 80 TID 02 TID This is WTP PDU (WAP-224-WTP) 1C=0001 1100 means Acknowledgement PDU. WSP PDU must be encapsulated in WTP PDU. | |||
| yanxh New member Username: Yanxh Post Number: 9 Registered: 11-2003 |
sorry, it's my fault. yes,just what you said, it 's a ACK pdu, which gw send to client. it's normal process. after you invoke a connect or post, you must send a ACK to gw, at the same time, GW will also send a ACK to client. which explain " received the package". you can see what 's the effect of ACK in wap-224. | |||
| Dilshod New member Username: Dilnab Post Number: 8 Registered: 11-2003 |
Hi All, and Happy New Year For the get request WAP gate sends to user agent: 16 fa ea 04 20 49 a1 92 .... I.. 04 3f fd 3c 37 a6 41 70 .?.<7.Ap 61 63 68 65 2f 32 2e 30 ache/2.0 2e 34 38 20 28 55 6e 69 .48 (Uni 78 29 20 50 48 50 2f 34 x) PHP/4 2e 33 2e 34 00 9d 04 3f .3.4...? df 0c 86 93 22 33 38 37 ...."387 34 65 2d 31 63 63 2d 33 4e-1cc-3 34 64 37 61 64 38 30 22 4d7ad80" 00 84 81 8d 02 01 cc 00 00 5a 26 00 14 70 c0 18 .Z&..p.. 10 00 00 00 00 00 3f 7f ......?. e8 70 bf d3 cf ff ff ff .p...... ff ff 80 7f e8 60 7f cf .....`.. f7 ff ff ff ff ff bf 7f ........ d0 60 07 1c 3b ff ff ff .`..;... ff ff 80 7f d0 40 e6 98 .....@.. 1b ff ff ff ff ff bf 7f ........ a0 40 ce 37 1d ff ff ff .@.7.... .................................. this is result WTP PDU that has Reply WSP PDU in it. I've found that a1 92 04 3f fd 3c 37 a6 is content type. What it means? Is there any tools that can decode WAP WSP content types, and where I can download it? Thanks | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1553 Registered: 10-2002 |
A1 alone is the content type, which equates to "image/vnd.wap.wbmp". See http://www.wapforum.org/wina/wsp-content-type.htm | |||
| Dilshod New member Username: Dilnab Post Number: 9 Registered: 11-2003 |
Ok, I've understand the fields of the header. There are another question. For mobile phones to download Midlets, .JAR and .JAD must be added to web server mime types. Must WAP gate also support this mime types? How it must encode this mime types? If this is true where can I find binary codes for new text/vnd.sun.j2me.app-descriptor application/java-archive types, as they are not in WSP content type doc? Thanks | |||
| Dilshod New member Username: Dilnab Post Number: 10 Registered: 11-2003 |
Hi There is another questions: Does WMLS Script executed in WAP gateway? Thanks | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1601 Registered: 10-2002 |
Dilshod, If there is not a content type code, generally the WAP gateway will just encode the content type as a text string instead of a binary code. In some of the examples above, you might notice that "application/vnd.wap.mms-message" is encoded in the PDUs as a text string. This is because some early phones came out with MMS support before a binary code was assigned for this content type, and so it has become somewhat common to just encode this content type as a text string instead. So to answer your question, generally a WAP gateway does not need to do anything special to support the Java types (as long as it can handle larger files). WMLScript is a client side scripting language. It is executed in the WAP browser client. | |||
| Dilshod New member Username: Dilnab Post Number: 11 Registered: 11-2003 |
Hi, Can NowSMS WAP/MMS Gate support WAP and MMS service for CDMA 1X? I mean that there are diferences in handset soft and noty fully match WAP Forum standarts. For example different WML/WMLS, and MMS over HTTP/TCP. Thanks | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 1745 Registered: 10-2002 |
Hi Dilshod, Now.WAP is fine for CDMA. At present, the Now SMS/MMS Gateway will only work as an MMSC in a CDMA environment if you have a separate WAP push proxy gateway that supports CDMA. The MMS notification message is sent over a WAP push message. NowSMS can generate these messages directly for GSM SMS, but cannot for CDMA SMS. For a CDMA environment, the NowSMS MMSC needs to be able to submit a PAP request to a push proxy gateway as described in the following document: http://www.nowsms.com/support/bulletins/tb-nowsms-007.htm -bn | |||
| richard graf Unregistered guest |
hello. i have got a new phone, and i dont know how to set up my mms messages and WAP settings, my dad got the phone first, and the mms and wap got sent to him, but i dont have it to my suim card, thanks | |||
| Dilshod New member Username: Dilnab Post Number: 12 Registered: 11-2003 |
Some CDMA 1x phones make TCP connection with WAP gate, and sends/receives HTTP/HTML packets. What about this type of gates? | |||
| Ravikanth Bollapragada Unregistered guest |
Hi Bryce, Thank you very much for sharing sample PDU! It really helped me a lot in sending MMS successfully, from my client. Will come back soon, Ravikanth Bollapragada http://www.bollapragada.com/ravikanth.htm | |||
