Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what is the vernacular MMS protocol". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Notice

Since the first step is also an SMS protocol, let's review the composition of the SMS protocol. It looks like this:

Including UDH and UD, what are the values of UDH and UD in the MMS notification?

Let's start with UDH, which contains 2 port information (wap-push:2948,wap-wsp:9200). These two ports are ports registered by IANA. As we said later, all we need to know is that it takes 4 bytes (2 bytes for each port) to store these two ports. We happen to have an IEI of 0x05 (Application port addressing scheme, 16 bit address), which means that IED contains 16-bit port information. The UDH we notified is like this:

The hexadecimal of 2948 is 0x0B84 and the hexadecimal of 9200 is 0x23F0, so the final UDH is: 0x05 0x04 0x0B 0x84 0x23 0xF0

Then let's talk about UD. As we mentioned earlier, we will bring the address of the MMS file to our notice, and when the phone receives the notification, we will go to this address to download the MMS file. Therefore, the MMS address must be in our UD, so what else needs to be included in the UD?

I wonder if you have noticed what MMS looks like on your mobile phone. MMS will certainly have the main information such as pictures and videos, but it will also send information such as who, the subject and the size of the MMS. What information do we need to include in our notification? in fact, the above is all the information contained in our MMS file, but the main information such as pictures and videos are not needed in the notice, otherwise what is the need for the notice? then the rest is the information that needs to be brought in the notice, including the sender, the subject, and the size of the MMS.

Now that we know what information needs to be stored in UD, let's take a look at the specific composition of UD.

Old rule, before that, let me introduce a concept.

WSP (Wireless Session Protocol): this is a protocol based on HTTP1.1 and has its own coding method

When we talked about UDH, we mentioned that there are two ports of information (wap-push, wap-wsp). These two ports exactly correspond to the two processes of our MMS, which can be used as the destination and source. Our UD is also stored in WSP coding. Here is a brief description of how WSP is encoded.

WSP coding can actually be regarded as key-value coding, and there are two kinds of key coding, one can be regarded as built-in key, and the other is custom key.

The built-in key is represented by a byte of content. Custom key will be encoded with a special string encoding method. Value is the same as a custom key. If a string is encoded with a special string encoding method, the number will be encoded with a special numeric encoding method.

Our UD composition also contains information headers and information bodies, which are not UDH and UD in short messages, but information headers and information bodies in WSP.

Information head

The WSP header is very simple, including a TID and a PDU TYPE, each occupying one byte. TID does not need to care about it. When we care about pdu_type=6, it means that it is a wap-push and OK.

For example, let's assume that the WSP header for TID=0 is: 0x00 0x06

Information body

Here we introduce another concept.

MMSEP (Multimedia Messaging Service Encapsulation Protocol): MMS encapsulation protocol, which is based on WSP protocol

MMSEP also contains headers and bodies. Remember when we said that notifications are similar to MMS files? In fact, the same part of the MMS file and the notification is the information header of MMSEP, and the extra pictures and videos are the information body of MMSEP. In fact, the notification is a MMSEP with empty information body.

The MMSEP header specifies that a content_type,content_type is also encoded according to a special string encoding method. For example, the content_type of MMS notification is: the content_type of application/vnd.wap.mms-message,MMSEP is different from that of ordinary content_type, and the content_type of MMSEP can take parameters and participate in coding together. The content_type of MMS notification has a parameter X-Wap-Application-ID=x-wap-application:mms.ua.

Here we take a brief look at the content_type results: 0x22 0x61. 0x00 0xAF 0x84

Let's roughly explain this string of codes. Do you remember the WSP coding method mentioned earlier? The key of X-Wap-Application-ID is built-in and is represented by 0xAF, and x-wap-application:mms.ua is also represented by 0x84. Let's take a look at the front, because application/vnd.wap.mms-message is not a built-in key, so it has to be encoded according to a special string encoding. The first bit represents the length 0x22, followed by 0x61. 0x00 is the encoded content (omitted here)

Let's go on to see that there will be some other information in the MMSEP header in addition to the sender, subject, and MMS size that we mentioned earlier. Let's introduce them one by one.

Version: indicates the WSP encoded version used

Message_type: indicates the type of MMS

Transaction_id: represents the ID of things

Message_class_id: indicates the MMS classification ID

Expiry: indicates the validity period of MMS

Subject: indicates the title

Location: indicates the address of the MMS file (as we mentioned earlier, WSP is a HTTP-based protocol, here it can be a HTTP address)

From: indicates the sender

Here we specifically explain what kind of MMS message_type,message_type represents. For example, message_type=2 says it is a notification, and message_type=4 says it is an MMS file.

So at this point, the rest of our notification UD is known, and this is what it looks like:

Most of the key here are built-in, so let me give you a few examples, such as

0x8D90 0x80 indicates that this is version,0x90, which means that the value is 1.0.

0x8A80 stands for msg_class_id=personal

0x8C82 stands for message_type=2

0x98 for transaction_id,0x88, expiry,0x89 for from,0x8E, size,0x83 for location,0x96, subject.

There is no key of the exemplary values, so their values need to be encoded with special strings or numbers

At this point, the part of our notice is over, and the whole notice is about: 0x05 0x04 0x0B 0x84 0x23 0xF0 0x00 0x06 0x22 0x61. 0x00 0xAF 0x84 0x8D90 0x8A80 0x8C82 0x98. 0x88. 0x89. 0x8E. 0x83. 0x96.

One additional point here, as you may have noticed, from the end result, since our MMS notifications are the same as ordinary text messages, and the things we encode are likely to exceed the limit of SMS bytes, it is also possible that a notification is divided into multiple messages. In this case, we cannot omit the necessary information. What we can do is to shorten the location (uri).

Finally, let's take a look at what the notification looks like at the agreement level:

MMS document

When we talked about the notification earlier, we mentioned that the MMS file actually contains more pictures and videos than the MMS notification. From the point of view of the protocol, there are more information bodies than the MMS notification (information part MMSEP header). In fact, there are pictures and videos in the information body, and the MMS file looks like this:

We have already introduced MMSEP header, so only some of the values of header in our MMS file are different, and the others are the same as when we were notified. I will list the different values for you below.

Content_type: application/vnd.wap.multipart.related or application/vnd.wap.multipart.mixed

Message_type: as mentioned before, if it is an MMS file message_type=4

Date: indicates the time when the MMS was generated. Unlike the expiry of the notification, the MMS file is date.

This is the end of the content of "what is vernacular MMS Agreement". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.