彩信的交互过程。对彩信客户端实现者来说，我们主要关心：彩信发送方与 MMS Proxy-Relay 之间的交互和彩信接收方和 MMS Proxy-Relay 之间的交互，这包括 下列几个过程。  发送过程。这是彩信发送方把彩信发送给 MMS Proxy-Relay 的过程，MMS Proxy-Relay 在收到彩信后会给发送方一个确认消息。  通知过程。为了把彩信投递给接收方，MMS Proxy-Relay 要通过 PUSH 协议 给接收方发送一条彩信通知消息，这个消息通常是一条特殊短信，里面包含 彩信的位置 URL。  彩信接收。接收方收到彩信通知后，从中取出 URL，然后通过标准的 HTTP GET 请求从 MMS Proxy-Relay 上获取彩信。 

 彩信回执。当 MMS Proxy-Relay 成功的通知彩信接收方后，它会给彩信发 送方发送一个消息表明彩信投递成功。  彩信阅读回执。彩信阅读回执是一条新彩信，它的传递过程和普通彩信没 有什么差别，只是不能再有阅读回执。 彩信的 PDU。PDU 即协议数据单元，对应前面每种消息的消息格式。彩信的 PDU 和 HTTP 协议极为类似，当然相对来说要简单多了。它定义了一些常用的消息域， 有的消息域是公有的，每种消息都可以使用，有的消息域是专用的，只有特定的 消息才能使用。除了常用的消息域外，也可以自定义消息域，自定义消息域以 X-打头，但不能以 X-Mms-打头。常用的消息域如： 

 X-Mms-Message-Type  X-Mms-Transaction-ID  X-Mms-MMS-Version  Date  From  To  Cc  Bcc  Subject  X-Mms-Message-Class  X-Mms-Expiry  X-Mms-Delivery-Time  X-Mms-Priority  X-Mms-Sender-  Visibility  X-Mms-Delivery-Report  X-Mms-Read-Reply  Content-Type PDU 的类型有：  发送请求。m-send-req(终端<发送方>->彩信中心)  发送确认。m-send-conf(彩信中心->终端<发送方>)  彩信通知。m-notification-ind(发送 PUSH：彩信中心<通过 PUSH 协议>-> 终端<接收方><特殊短信，包含 URL>)  通知回应。m-notifyresp-ind(收到 PUSH 回应：终端<接收方>->彩信中心)  获取彩信回应。m-retrieve-conf（彩信中心->终端<接收方>）  接收确认。m-acknowledge-ind(终端<接收方>->彩信中心)  彩信回执。m-delivery-ind(彩信中心->终端<发送方>) 

获取彩信只是一个普通的 HTTP GET 请求，而没有专门的 PDU。 彩信的 PDU 编码。彩信 PDU 在语义上与 HTTP 协议类似，但是其编码方式并不一 样，为了充分利用带宽，彩信 PDU 采用二进制方式编码。其编码规则很简单，预 定义的消息域的 KEY 都有唯一的单字节编码，如： Key Bcc Cc Content-Location Content-Type Date Delivery-Report Delivery-Time Expiry From Message-Class Message-ID Message-Type MMS-Version Message-Size Priority Read-Reply Report-Allowed Response-Status Response-Text Sender-Visibility Status Subject To Transaction-Id 编码 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 而消息域的 Value 部分，如果只有几个固定的可选值，这几个值也用单子节的编 码，由于这些值只出现在特定的上下文中，所以无需要全局唯一。