Network Working Group Jianping Zheng Internet-Draft Yichuan Wu Intended Status: Experimental China Mobile Communications Corporation Expires: December 22, 2017 Weimin Lei Wei Zhang Hao Li Northeastern University June 21, 2017 An Extension for SIP Instant Message Using Publish/Subscribe Mode draft-zhengjp-sipcore-sipim-ext-01 Abstract SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) is a protocol suite for instant messaging (IM) service, but it is inefficient in processing session-mode instant message due to its complex signaling processes and heavy header overheads, which makes it difficult to meet the QoE (quality of experience) requirement, especially in the usage scenario of mobile Internet and other traffic sensitive networks. This document describes an alternative Session Initiation Protocol (SIP) extension for instant messaging service. The extension uses the publish-subscribe mode to simplify signaling procedures and introduces message user agent (MUA) to publish and receive message, and message broker (MB) as an intermediary to exchange messages between MUAs. Message is tagged with a topic, and the lightweight message format is more suitable for traffic sensitive networks. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Zhengjp, et al Expires December 22, 2017 [Page 1] Internet-Draft sipim-ext June 21, 2017 This Internet-Draft will expire on February 08, 2017. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5 Entities Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 MUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1.1 User Identity(ID) and User Name . . . . . . . . . . . . 8 5.1.2 Connection Maintenance . . . . . . . . . . . . . . . . 9 5.1.3 Topic Subscription and Message Publication . . . . . . 9 5.1.4 Message ID Generation . . . . . . . . . . . . . . . . . 9 5.1.5 Session Termination . . . . . . . . . . . . . . . . . . 9 5.2 MB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.1 Request Authentication . . . . . . . . . . . . . . . . 10 5.2.2 Connection Maintenance . . . . . . . . . . . . . . . . 10 5.2.3 Sending Responses . . . . . . . . . . . . . . . . . . . 10 5.2.4 Processing Offline Messages . . . . . . . . . . . . . . 10 5.2.5 Other Features . . . . . . . . . . . . . . . . . . . . 10 6 Topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1 Topic Policy . . . . . . . . . . . . . . . . . . . . . . . 11 6.2 Organization of Topic . . . . . . . . . . . . . . . . . . . 11 6.3 Topic-based Message Routing . . . . . . . . . . . . . . . . 12 Zhengjp, et al Expires December 22, 2017 [Page 2] Internet-Draft sipim-ext June 21, 2017 7 Message Formats . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1.1 Fixed Header . . . . . . . . . . . . . . . . . . . . . 14 7.1.2 Variable Header . . . . . . . . . . . . . . . . . . . . 14 7.2 CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3 CONNACK . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.4 PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.5 PUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.6 SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.7 SUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.8 UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 22 7.9 UNSUBACK . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.10 PINGREQ . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.11 PINGRSEP . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.12 DISCONNECT . . . . . . . . . . . . . . . . . . . . . . . . 26 8 Compatibility Considerations . . . . . . . . . . . . . . . . . 26 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 28 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1 Normative Reference . . . . . . . . . . . . . . . . . . . 28 10.2 Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Zhengjp, et al Expires December 22, 2017 [Page 3] Internet-Draft sipim-ext June 21, 2017 1 Introduction Instant messaging (IM) services enable real-time text and multimedia exchange and online presence awareness. The main service characteristics of IM include various media type (text, audio, video, picture, emoji, etc.) and high interactivity (group chat, online game etc.). Besides some proprietary IM protocols used by software deployed today, IM service can be implemented by some open standards, such as Extensible Messaging and Presence Protocol (XMPP)[RFC6120][RFC6121], Common Profile for Instant Messaging (CPIM)[RFC3860][RFC3922], SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)(which consists of a series of standards)[IETF SIMPLE WG]. And SIMPLE is comparatively complete among these standards and has been adopted by many vendors as the standard of instant messaging applications. SIMPLE is a SIP-based protocol suite, which has been applied in many applications, such as the presence and the instant messaging. However, with the development of the multimedia and related storage technology, and the changing requirements of users, the existing SIMPLE framework has limited the further development of IM service, which is discussed as follows. 1) SIMPLE uses SIP[RFC3261] and MSRP (The Message Session Relay Protocol)[RFC4975][RFC4976] as the core protocols, and defines two modes of instant messaging: page mode and session mode. Page mode is suitable for transmitting short messages by the way of SIP MESSAGE[RFC3428], but compared with the message content, the message header overhead is heavy in most cases, which has decreased the overall transmission efficiency. Session mode adopts SIP and MSRP to transmit long messages or files. It firstly establishes a session between participants by SIP signaling and uses MSRP to transmits messages. However, the procedure of session establishing and terminating is relatively complex and will introduce extra overhead, and thus affects the overall efficiency of message transfer. MSRP is a text-based connection oriented protocol and the extra overhead of the message is big, which will also lower execution efficiency to some extent. 2) For IM service, store-and-forward mode turns to be the main application patterns, however, SIMPLE framework still uses Peer- to-Peer mode in which messages can be transmitted between participants directly, but when the communication is interrupted, the connection between participants should be re-built and the message being transferred should be re-transmitted between sender and receiver. Store-and-forward mode adopts a middleware to receive and forward messages, in which the process of message sending and receiving is asynchronous and the middleware assures reliable message delivery. Zhengjp, et al Expires December 22, 2017 [Page 4] Internet-Draft sipim-ext June 21, 2017 3) The main usage scenario of instant message is mobile Internet and mobile phones are one of the most important communication devices available these days. In mobile Internet, the IP address of the mobile device is time-varying as it moves. To provide the addressability of the endpoint, the mobile device must register to server constantly when its address changes. For a SIP-based instant message application, the vibrating registration which caused by the changing IP address will cause a huge overhead of traffic and power. The mobile device is sensitive to the traffic and power consumption in mobile Internet, and the vibrating registration will decrease the quality of experience of users. 4) Group chatting is an important feature of IM service, and the implementation of group chatting by SIMPLE uses the SIP Conference service for references. RFC7701 provides a group messaging frame based on SIP and MSRP, which requires all participants maintain a MSRP connection with MSRP Switch. However, long-time connection with the Switch would cause a great waste of network resources when there is no traffic transfer and the re-establishment of the connection will waste more when a short message needs to be transmitted. This method will cause a higher traffic and power consumption and thus reduce service experience of user. 5) The scaling problem is also a severe problem for SIMPLE-based IM, especially relevant considering the explosive growth in sales of users. For a large-scale network, the management and process of message can become very complex, which will affect the promotion of execution efficiency and resource utilization. Much of the functions can be realized through SIMPLE, but the disadvantages, such as high traffic demand, inefficient execution, waste of network resource and complicated functionality extension, have impeded the development of SIP-based IM service. In addition, instant messaging applications based on SIMPLE or other related protocol suites are primarily enterprise-oriented, which doesn't apply to use on a large scale. To solve these problems, this document extends the current SIP, adding two kinds of logical entities named Message User Agent (MUA) and Message Broker (MB). MUA is a user agent, which is responsible for publishing and receiving messages, creating, modifying and deleting a group. MB is in charge of message receiving, storing and forwarding, and in the meanwhile it manages the group. Each message is associated with a related topic and the transfer method is based on the publish/subscribe mode which decouples publisher and receiver dependencies, and reduces the system extension problem. 2 Terminology Zhengjp, et al Expires December 22, 2017 [Page 5] Internet-Draft sipim-ext June 21, 2017 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3 Definitions To extend SIP, this document defines: 1)MUA (Message User Agent): MUA can be authenticated and registered with the SIP Server, which is exactly the same as the SIP UA, then MUA must register with the MB and maintain a TCP connection with MB. MUA is responsible for producing, subscribing and publishing messages to relevant Topic. It receives messages from MB, manages the users' configuration files and participates in creation, modification and deletion of a group. It's also used for authentication and register of user. 2) MB (Message Broker): MB deals with the authentication, registration and Topic subscribing request from MUA and manages user configuration files. And it manages Topic, receives, stores and forwards the messages, and manages the group chat. It interacts with other SIP entities to complete authentication and registration for users. 3) Topic: Topic is structured as a layered organization. Topic name is the tag of a kind of or a set of instant message. It is generated in MUA, and published to MB, and finally stored in MB. MUA updates the message contents of a Topic, and MB will match the subscribers of the Topic and push the message to those subscribers. And the group chatting topic is generated in MB and must be globally unique. 4) Message Configuration Files: Message Configuration Files include the users' basic information, messaging strategy and group information. When the users start registering, they will upload the configuration documents to MB and MB will complete the subscription of relevant Topic for the users according to it. 4 Overview SIMPLE is an open instant messaging (IM) and presence protocol suite based on SIP and MSRP, but its complex signaling processes and heavy header overheads has decreased the execution efficiency, which has affected the user experience. To solve these problems, this document introduces two logical entities: MUA and MB, which are responsible for SIP message service. This scheme uses store-and-forward mode to transmit messages instead of the peer-to- peer mode. The store-and-forward mode used in the proposed document is publish/subscribe mode. Publish/subscribe mode, also called Observer mode, is a kind of messages transport pattern which can be Zhengjp, et al Expires December 22, 2017 [Page 6] Internet-Draft sipim-ext June 21, 2017 applied to store-and-forward mode effectively. Each message is associated with a related topic. MUAs generate topics according to some specific rules and then publish to the MB. MUAs subscribe a topic from MB and become relevant subscribers. When the message sender publishes the messages to topic, MB publishes the messages to all the relevant subscribers. And the advantages of the proposed solution are discussed as follows: (1) Decoupling a. Decoupling publisher from receiver i. Space decoupling When sending messages, the publisher doesn't need to know whether the receiver is online, a relevant topic subscriptions relationships will help the MB publish the messages that the publisher published to the relevant subscribers. ii. Time decoupling The publisher and receiver don't need to establish connection simultaneously to assure the immediacy and efficiency. iii. Synchronization decoupling The publisher doesn't need to establish the synchronization relationship with the receiver. It publishes the messages to MB and the receiver receives in an asynchronous way, i.e., MUA-to-MB, MB-to-MUA, by keeping a connection with MB. b. Decoupling the user from terminal device For multi-terminal user, the user just maintains a weak relation with the terminal device. The terminal device keeps the synchronization relationship with MB and subscribes topic independently. (2) Reducing the complexity of implementation All the messages including one-to-one messages, one-to-many messages and group messages can be defined as the form of topic and transmitted as the publish/subscribe mode. This method makes different kinds of messages have the approximate cost. Furthermore, it reduces the implementation complexity of group chatting. (3) Stateless processing In the store-and-forward mode based on publish/subscribe pattern, message publishing is asynchronous with message receiving, so MB doesn't need to maintain the state- transition relationship for message publishing and forwarding. Zhengjp, et al Expires December 22, 2017 [Page 7] Internet-Draft sipim-ext June 21, 2017 Moreover, this mode gets rid of the dependence of transaction and reduces the cost. (4) Expansibility Publish/subscribe mode achieves distributed architecture, parallel operations, message buffer and tree routing or mesh routing. Therefore, it could achieve a high expansibility, and suit for the large-scale usage scenario and improve the insufficiency caused by the tightly coupled and data-center service. (5) Environmental suitability In publish/subscribe mode, publishers and receivers are loosely coupled, and each of them only needs to keep a connection with MB, which supports the mobility, frequent disconnection of mobile Internet. (6) Service openness The extension of a new application or function in SIMPLE is complex due to the tedious process of the extension of SIP/SDP, but in topic mode, the application can be realized by generating different Topics in terms of the requirement and the others can subscribe the topics that they are interested in. Therefore, this method enables the definition and realization of service in a more flexible way and supports the openness of service. The two new entities (i.e., MUA and MB, which will be described in more detail in the subsequent sections) adopt the binary-based message format refers to the MQTT (Message Queuing Telemetry Transport)[OASIS Standard MQTT] to better support the mobile Internet scenario. MB needs to register to the Proxy or the application server (AS) in charge of message service for the purpose of legality. The registration mechanism of MUA is similar with SIP UA but not the same, the difference is that MUA is responsible for message service and needs to request authentication to Proxy or AS. Proxy or AS would assign a MB for MUA based on the current system load. 5 Entities Behavior 5.1 MUA 5.1.1 User Identity(ID) and User Name User ID is an identity that is provided by MB to uniquely represent a MUA and is transparent to the user, and is used for authentication and message transmission. User can use a unique user name by himself and the user name is associated with the User ID. Zhengjp, et al Expires December 22, 2017 [Page 8] Internet-Draft sipim-ext June 21, 2017 5.1.2 Connection Maintenance A TCP connection needs to be established between MUA and MB. And a heartbeat mechanism is employed to maintain a long-lived connection between client(MUA) and MB. Communication among MUAs is associated with Topic. This topic-based transport pattern provides a loose coupling relationship between the publisher and receiver, and makes the implementation of one-to-one message service and group message service easier. And it's also helpful to decouple the user and terminal and support multi-terminal mode easily. 5.1.3 Topic Subscription and Message Publication MUA subscribes to the topics it is interested in by sending a subscription message to MB. And the message should include the interested topics. When a message is published to a topic, MB will match the subscribers and publish the message to subscribers, and the published message includes the topic information and message content. Different types of message have different transmission strategies. For plain text message, MUA sends data to MB directly, and then MB sends it to MUA who has subscribed this Topic. For multimedia message such as pictures, files and so on or the text message is lengthy, sender sends data to specialized multimedia server and the server returns relevant URL link. Then MUA puts the URL link in the payload of message and publishes to an associative topic stored in MB. When MB receives, it sends the message to all relevant subscribers. Finally, the subscribers will parse the message to get the URL and downloads multimedia data from the multimedia data server. 5.1.4 Message ID Generation MUA needs to generate a local unique message ID for a new message. The message ID is used to associate response messages with their corresponding request messages and thus ensures the transmission reliability. 5.1.5 Session Termination When terminating session for some reason, the MUA will send a message to MB and aborts the connection with MB. 5.2 MB MB is responsible for the authentication of MUA, connection management, message forwarding and the storage of users' offline messages and message configuration file. Zhengjp, et al Expires December 22, 2017 [Page 9] Internet-Draft sipim-ext June 21, 2017 5.2.1 Request Authentication When MUA sends a message to request connection, MB must authenticate the request by comparing the token value in request message with the token in uniform authentication platform. If the match is successful, MB will pre-subscribe the topics of user's message configuration file. If failed, MB will reject the connection. 5.2.2 Connection Maintenance MB maintains the connection with client(MUA) and replies to the MUA's heartbeat request. If MB does not receive a message within a reasonable amount of time from MUA, MB will mark the connection with MUA is unreachable. 5.2.3 Sending Responses When receiving a request message from MUA, MB will send a corresponding response message back according to different message types. And the response message has the same message ID with the corresponding request message. The response message indicated that the request massage has successfully received. 5.2.4 Processing Offline Messages If the message receiver is offline, the message is stored on MB so that it can be processed once the related receiver is back online. 5.2.5 Other Features MB has some other features: Topic Parsing: MB is responsible for parsing a new topic generated by MUA and maintains the subscription policy to determine whether other user is permitted to subscribe to the topic. For example, topic named by the User ID is restricted to be subscribed only by user himself. Permission Checking: MB performs ACL permission checkout and filters the messages in relevant Topic of MUA. The filtering operation can be set by system as well as its user. For example, if a Topic is set "read", its user will only have the permission of receiving, if a Topic is set "write", its user will only have the permission of sending. State Presenting: all the states are presented by user presence. Presence is presenting the state of any terminal. State is related to the type of terminal. When a user's presence state changes, MB will inform all his friends. Zhengjp, et al Expires December 22, 2017 [Page 10] Internet-Draft sipim-ext June 21, 2017 MB to MB: it is the connection between two MBs and is considered as the communicating extension between client and server. 6 Topic 6.1 Topic Policy Topic can be considered as a class of instant message or control message (which is used for the system management). And the MUA of receiver needs to subscribe to the topic it is interested in. For different types of topics, the subscription rules are different. The first type is user-related topic which can be personally subscribed to, i.e., topic belongs to a related user, and the user is the only subscriber of the topic, and others are forbidden to subscribe to, like one-to-one IM topic. Although the subscription of topic is forbidden to other users, the publishing is permitted, and the other users can publish IM to a user-related topic and MB forward the message to the unique subscriber. The second type is conditional open topic in which multiple subscriber is permitted under a certain condition. For a group IM topic, only the creator of the group and the users who have been invited could subscribe to the topic. For different message types, the processes are different. This document defines the service profile identifiers to distinguish different message types. For example, the one-to-one messages' service profile identifier is defined as '100' while the group messages' is '200'. The one-to-one messages' topic is /100/User ID while the group messages' is /200/Group ID. For one-to-one messages service, MUA subscribes to the topic it is interested in, while for group messages service, all the users in the group subscribe to a same group topic. 6.2 Organization of Topic The topic level separator is used to introduce structure into the Topic Name. If present, it divides the Topic Name into multiple "topic levels". The forward slash ('/' U+002F) is used to separate each level within a topic tree and provide a hierarchical structure to the Topic Names. Some topics are defined according to the user behavior such as the topic of adding friends is 'user/friend/new', deleting friends corresponds to 'user/friend/delete', user's IM topic is user/chat while the topic of state presenting is presence/user. Typically, the users transmit instant messages with each other in user/chat. Using adding friends as an example, when Alice wants to add Bob as friend, she sends request message to BoB's topic, i.e., Zhengjp, et al Expires December 22, 2017 [Page 11] Internet-Draft sipim-ext June 21, 2017 Bob@example.com/friend/new. Then Bob sends response message to Alice's topic, i.e., Alice@example.com/friend/new. If Bob accepts the request, both of them should update their Message Configuration File. 6.3 Topic-based Message Routing MB operates the function of message routing based on Topic. For a large scale network, a multi-domain deployment plan is introduced. Each domain can administer a certain number of users and the related topics. Each topic name indicates the domain that the topic belongs to. When MUA sends a message to the topic, the MB which the MUA connected will parser the topic name and obtain the domain, and send the message to the related domain. The MB which stores the topic will receive the message and forward the message to subscriber(s). 7 Message Formats 7.1 Overview Referring to MQTT protocol[OASIS Standard MQTT], this scheme defines 11 kinds of message types which are represented as a 4-bit unsigned value. These messages types can be divided into 4 categories as illustrated in Figure 7.1. Zhengjp, et al Expires December 22, 2017 [Page 12] Internet-Draft sipim-ext June 21, 2017 +--------------+------------+-------+-----------+----------------+ | Category | Name | Value | Direction | Description | | | | | of folw | | +--------------+------------+-------+-----------+----------------+ | | CONNECT | 1 | MUA -> MB | MUA request to | | | | |or MB-> MUA| connect to MB | | +------------+-------+-----------+----------------+ | Connection | CONNACK | 2 | MB -> MUA | Connect | | Class | | | | acknowledgment | | +------------+-------+-----------+----------------+ | | DISCONNECT | 3 | MUA -> MB | MUA is | | | | | | disconnecting | +--------------+------------+-------+-----------+----------------+ | | PUBLISH | 4 | MUA -> MB | Publish message| | Publication | | |or MB-> MUA| | | Class +------------+-------+-----------+----------------+ | | PUBACK | 5 | MUA -> MB | Publish | | | | |or MB-> MUA| acknowledgment | +--------------+------------+-------+-----------+----------------+ | | SUBSCRIBE | 6 | MUA -> MB | MUA subscribe | | | | | | request | | +------------+-------+-----------+----------------+ | | SUBACK | 7 | MB -> MUA | Subscribe | | Subscription | | | | acknowledgment | | Class +------------+-------+-----------+----------------+ | | UNSUBSCRIBE| 8 | MUA -> MB | Unsubscribe | | | | | | request | | +------------+-------+-----------+----------------+ | | UNSUBACK | 9 | MB -> MUA | Unsubscribe | | | | | | acknowledgment | +--------------+------------+-------+-----------+----------------+ | Keep-alive | PINGREQ | 10 | MUA -> MB | PING request | | Class +------------+-------+-----------+----------------+ | | PINGRESP | 11 | MB -> MUA | PING response | +--------------+------------+-------+-----------+----------------+ Figure 7.1 - Message types The message consists of up to three parts, always in the following order as illustrated in Figure 7.2. Zhengjp, et al Expires December 22, 2017 [Page 13] Internet-Draft sipim-ext June 21, 2017 +-------------------------------+ | Fixed header | +-------------------------------+ | Variable header | +-------------------------------+ | Payload | +-------------------------------+ Figure 7.2 - Message structure 7.1.1 Fixed Header Each message contains a fixed header. Figure 7.3 illustrates the fixed header format. +-------+---+---+---+---+---+---+---+---+ |Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+---+---+---+---+---+---+---+---+ |byte 1 | Message Type | Flags | +-------+---------------+---------------+ |byte 2 | Remaining Length | +-------+-------------------------------+ Figure 7.3 - Fixed header format Message Type: byte 1, bits 7-4. Represented as a 4-bit unsigned value, different value expresses different message type. For example, value 1 expresses the CONNECT message while value 2 expresses the CONNACK message. Flags: remaining bits 3-0 of byte 1, specific to each kind message. Remaining Length: starts at byte 2, bits 7-0, the number of bytes remaining within the current message, including data in the variable header and the payload. The least significant seven bits of each byte encode the data, and the most significant bit is used to indicate that there are following bytes in the representation. The fixed header can be extended to four bytes at most. 7.1.2 Variable Header Some types of messages contain a variable header component. It resides between the fixed header and the payload. The content of the variable header varies depending on the message type. The Message Identifier field of variable header is common in several message types as illustrated in Figure 7.4. Zhengjp, et al Expires December 22, 2017 [Page 14] Internet-Draft sipim-ext June 21, 2017 +-------+---+---+---+---+---+---+---+ |Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | +-------+---+---+---+---+---+---+---+ |byte 1 | Message Identifier MSB | +-------+---------------------------+ |byte 2 | Message Identifier LSB | +-------+---------------------------+ Figure 7.4 - Message Identifier bytes Message Identifier: two bytes, non-zero, unique identification of a message. This specification defines 11 kinds of message types, including CONNECT, CONNACK, PUBLISH, PUBACK, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, PINGREQ, PINGRES and DISCONNECT. SUBSCRIBE, UNSUBSCRIBE, and PUBLISH messages MUST contain a non-zero 16-bit Message Identifier. Each time MUA sends a new message of one of these types it MUST assign it a currently unused Message Identifier. If MUA re-sends a message, then it MUST use the same Message Identifier in subsequent re-sends of that message. The Message Identifier becomes available for reuse after the MUA has processed the corresponding acknowledgement message form MB. For PUBLISH it is the corresponding PUBACK. For SUBSCRIBE or UNSUBSCRIBE it is the corresponding SUBACK or UNSUBACK. 7.2 CONNECT CONNECT, requesting connection, the fixed header as illustrated in Figure 7.5. +-------+---+---+---+----+---+---+---+---+ |Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+---+---+---+----+---+---+---+---+ |byte 1 |Message Type (1)| Reserved | +-------+---+---+---+----+---+---+---+---+ | | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | +-------+---+---+---+----+---+---+---+---+ |byte 2 | Remaining Length | +-------+--------------------------------+ Figure 7.5 - CONNECT message fixed header Message Type: 1, represent the CONNECT message; Flags: 0, reserved for future use; Remaining Length: uncertain, depend on the data in the variable header and the payload. Zhengjp, et al Expires December 22, 2017 [Page 15] Internet-Draft sipim-ext June 21, 2017 The variable header carries the protocol version information as illustrated in Figure 7.6. The protocol version is a UTF-8 encoded string that represents the protocol version "IM0". +-------+--------------+---+---+---+---+---+---+---+---+ | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+--------------+---+---+---+---+---+---+---+---+ |Protocol Version Information | +-------+--------------+---+---+---+---+---+---+---+---+ |byte 1 |Length MSB (0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +-------+--------------+---+---+---+---+---+---+---+---+ |byte 2 |Length LSB (4)| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | +-------+--------------+---+---+---+---+---+---+---+---+ |byte 3 | 'I' | 0 | 1 | 0 | 0 | 1 | 0 | 0 | 1 | +-------+--------------+---+---+---+---+---+---+---+---+ |byte 4 | 'M' | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | +-------+--------------+---+---+---+---+---+---+---+---+ |byte 5 | '0' | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | +-------+--------------+---+---+---+---+---+---+---+---+ Figure 7.6 - CONNECT message variable header As for the payload, it mainly includes personal information of user, such as username and authentication Token and heart-beats information. Username and authentication Token are the UTF-8 encoded strings. 7.3 CONNACK CONNACK is the MB's response of CONNECT, the fixed forehead as illustrated in Figure 7.7. +------+---+---+---+---+---+---+---+---+ |Bit |7 |6 |5 |4 |3 |2 |1 |0 | +------+---+---+---+---+---+---+---+---+ |byte 1|Message Type(2)| Reserved | +------+---+---+---+---+---+---+---+---+ | |0 |0 |1 |0 |0 |0 |0 |0 | +------+---+---+---+---+---+---+---+---+ |byte 2|Remaining Length (2) | +------+---+---+---+---+---+---+---+---+ | |0 |0 |0 |0 |0 |0 |1 |0 | +------+---+---+---+---+---+---+---+---+ Figure 7.7 - CONNACK message fixed header Message Type: 2, represent the CONNACK message; Zhengjp, et al Expires December 22, 2017 [Page 16] Internet-Draft sipim-ext June 21, 2017 Flags: 0, reserved for future use; Remaining Length: 2, represent that there are 2 bytes remaining within this message. The variable header mainly contains 2 components: CONNECT Acknowledge Flags and CONNECT Return code and its format is illustrated in Figure 7.8. +--------+-----------------+---+---+---+---+---+---+---+---+ | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +--------+-----------------+---+---+---+---+---+---+---+---+ |CONNECT Acknowledge Flags | Reserved |SP1| +--------+-----------------+---+---+---+---+---+---+---+---+ | byte 1 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | X | +--------+-----------------+---+---+---+---+---+---+---+---+ |CONNECT Return code | +--------+-----------------+---+---+---+---+---+---+---+---+ | byte 2 | | X | X | X | X | X | X | X | X | +--------+-----------------+---+---+---+---+---+---+---+---+ Figure 7.8 - CONNACK message variable header CONNECT Acknowledge Flags: Bits 7-1 are reserved and MUST be set to 0. Bit 0 (SP1) is the Session Present Flag. CONNECT Return code: represent the responding situation. 0 represents that the connection is successful, 1 represents that the connection is failed because of the unacceptable protocol version and 2 represents that connection is failed because of rejected user ID. 7.4 PUBLISH PUBLISH, sent from MUA to MB or from MB to MUA to transport an application message, the fixed header as illustrated in Figure 7.9. Typically, DUM = Duplicate delivery of a PUBLISH message; RETAIN = PUBLISH retain flag. Zhengjp, et al Expires December 22, 2017 [Page 17] Internet-Draft sipim-ext June 21, 2017 +--------+-----+-----+-----+-----+--------+-----+-----+------+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +--------+-----+-----+-----+-----+--------+-----+-----+------+ | byte 1 | Message Type (4) |DUM flag| Reserved |RETAIN| +--------+-----+-----+-----+-----+--------+-----+-----+------+ | | 0 | 0 | 1 | 1 | X | X | X | X | +--------+-----+-----+-----+-----+--------+-----+-----+------+ | byte 2 | Remaining Length | +--------+---------------------------------------------------+ Figure 7.9 - PUBLISH message fixed header Message Type: 4, represent the PUBLISH message; DUM flag: 1 indicates that it is a retransmission message and 0 indicates it isn't. RETAIN: 0 indicates that MB must not store the application message and must not remove or replace any existing retained message, while 1indicates that the MB must store it. Remaining Length: uncertain, depend on the data in the variable header and the payload. The variable header mainly contains 2 components: Topic Name and Message Identifier. Figure 7.10 shows a non normative example variable header, typically, the value of Topic Name set "a/b" and the value of Message Identifier set 10 Zhengjp, et al Expires December 22, 2017 [Page 18] Internet-Draft sipim-ext June 21, 2017 +--------+-----------------------------+---+---+---+---+---+---+---+---+ | |Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +--------+-----------------------------+---+---+---+---+---+---+---+---+ | Topic Name | +--------+-----------------------------+---+---+---+---+---+---+---+---+ | byte 1 |Length MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +--------+-----------------------------+---+---+---+---+---+---+---+---+ | byte 2 |Length LSB (3) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | +--------+-----------------------------+---+---+---+---+---+---+---+---+ | byte 3 | 'a' (0x61) | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | +--------+-----------------------------+---+---+---+---+---+---+---+---+ | byte 4 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | +--------+-----------------------------+---+---+---+---+---+---+---+---+ | byte 5 | 'b' (0x62) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | +--------+-----------------------------+---+---+---+---+---+---+---+---+ | Message Identifier | +--------+-----------------------------+---+---+---+---+---+---+---+---+ | byte 6 |Message Identifier MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +--------+-----------------------------+---+---+---+---+---+---+---+---+ | byte 7 |Message Identifier LSB (10) | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | +--------+-----------------------------+---+---+---+---+---+---+---+---+ Figure 7.10 - PUBLISH message variable header non normative example Topic Name: indicate which Topic is going to send data; Payload in PUBLISH carries the data which is described in Topic, i.e., the message content. 7.5 PUBACK PUBACK is the response of PUBLISH message and expresses that the message is received successfully by MB. The fixed forehead is illustrated in Figure 7.11. +-------+---+---+---+---+---+---+---+---+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+---+---+---+---+---+---+---+---+ | byte 1|Message Type(5)| Reserved | +-------+---+---+---+---+---+---+---+---+ | | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | +-------+---+---+---+---+---+---+---+---+ | byte 2| Remaining Length (2) | +-------+---+---+---+---+---+---+---+---+ | | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | +-------+---+---+---+---+---+---+---+---+ Figure 7.11 - PUBACK message fixed header Except the Message Type, the description of message field is the same Zhengjp, et al Expires December 22, 2017 [Page 19] Internet-Draft sipim-ext June 21, 2017 as CONNACK. The value of Message Type is 5. The variable header of PUBACK is a message descriptor as same as PUBLISH: +---------+---+---+---+---+---+---+---+---+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---------+---+---+---+---+---+---+---+---+ | byte 1 | Message Identifier MSB | +---------+-------------------------------+ | byte 2 | Message Identifier LSB | +---------+-------------------------------+ Figure 7.12 - PUBACK message variable header 7.6 SUBSCRIBE SUBSCRIBE expresses the subscription of Topic and the specification allows to define more than one Topic in a SUBSCRIBE. The fixed forehead is illustrated in Figure 7.13. +-------+---+---+---+---+---+---+---+---+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+---+---+---+---+---+---+---+---+ | byte 1|Message Type(6)| Reserved | +-------+---+---+---+---+---+---+---+---+ | | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | +-------+---+---+---+---+---+---+---+---+ | byte 2| Remaining Length | +---------------------------------------+ Figure 7.13 - SUBSCRIBE message fixed header Message Type: 6, represent the SUBSCRIBE message; Flags: 2, reserved for future use. Attention, it must be set to 2 respectively. The MB must treat any other value as malformed and close the network connection; Remaining Length: uncertain, depend on the data in the variable header and the payload. The variable header contains a Message Identifier. Figure 7.14 shows a variable header with Message Identifier set to 10. Zhengjp, et al Expires December 22, 2017 [Page 20] Internet-Draft sipim-ext June 21, 2017 +------+---------------------------+---+---+---+---+---+---+---+---+ | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +------+---------------------------+---+---+---+---+---+---+---+---+ |Message Identifier | +------+---------------------------+---+---+---+---+---+---+---+---+ |byte 1|Message Identifier MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +------+---------------------------+---+---+---+---+---+---+---+---+ |byte 2|Message Identifier LSB (10)| 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | +------+---------------------------+---+---+---+---+---+---+---+---+ Figure 7.14 - SUBSCRIBE message variable header The payload of a SUBSCRIBE message contains a list of Topic Filters indicating the Topics to which the MUA wants to subscribe. The Topic Filters in a SUBSCRIBE message payload MUST be UTF-8 encoded strings. The payload is illustrated in Figure 7.15. +-----------+---+---+---+---+---+---+---+---+ |Description| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-----------+---+---+---+---+---+---+---+---+ |Topic Filter | +-----------+-------------------------------+ |byte 1 |Length MSB | +-----------+-------------------------------+ |byte 2 |Length LSB | +-----------+-------------------------------+ |bytes 3..N |Topic Filter | +-----------+-------------------------------+ Figure 7.15 - SUBSCRIBE message payload 7.7 SUBACK SUBACK is MB's response of SUBSCRIBE. The fixed forehead is illustrated in Figure 7.16. +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 1| MQTT Message Type (7) | Reserved | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 2| Remaining Length | +-------------------------------------------------------+ Figure 7.16 - SUBSCRIBE message fixed header Zhengjp, et al Expires December 22, 2017 [Page 21] Internet-Draft sipim-ext June 21, 2017 Except the Message Type, the description of message field is the same as PUBACK. The value of Message Type is 7. The variable header contains the Message Identifier from the SUBSCRIBE message that is being acknowledged. Figure 7.17 illustrates the format of the variable header. +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 1| Message Identifier MSB | +-------+-----------------------------------------------+ | byte 2| Message Identifier LSB | +-------+-----------------------------------------------+ Figure 7.17 - SUBSCRIBE message variable header The payload contains a list of return codes. Each return code corresponds to a Topic Filter in the SUBSCRIBE message being acknowledged. The order of return codes in the SUBACK message must match the order of Topic Filters in the SUBSCRIBE message. Figure 7.18 illustrates the format of the variable header. +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | | Return Code | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 1| X | 0 | 0 | 0 | 0 | 0 | X | X | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ Figure 7.18 - SUBSCRIBE message payload Allowed return codes: 0x00 - Success; 0x80 - Failure. 7.8 UNSUBSCRIBE UNSUBSCRIBE expresses canceling the subscription of a Topic and the specification allows canceling subscription of different Topics at a time. The fixed forehead is illustrated in Figure 7.19. Zhengjp, et al Expires December 22, 2017 [Page 22] Internet-Draft sipim-ext June 21, 2017 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 1| Message Type (8) | Reserved | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 2| Remaining Length | +-------+-----------------------------------------------+ Figure 7.19 - UNSUBSCRIBE message fixed header Except the Message Type, the description of message field is the same as he UNSUBSRIBE. The value of Message Type is 8. The variable header is the message descriptor, as illustrated in Figure 7.20. +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 1| Message Identifier MSB | +-------+-----------------------------------------------+ | byte 2| Message Identifier LSB | +-------+-----------------------------------------------+ Figure 7.20 - UNSUBSCRIBE message variable header The payload for the UNSUBSCRIBE message contains the list of Topic Filters that the MUA wishes to unsubscribe from. The Topic Filters in an UNSUBSCRIBE message must be UTF-8 encoded strings. Figure 7.21 shows a non normative example payload, typically, it set two Topic Filters, the one is "a/b" and the other one is "c/d". Zhengjp, et al Expires December 22, 2017 [Page 23] Internet-Draft sipim-ext June 21, 2017 +------------+--------------+---+---+---+---+---+---+---+---+ | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +------------+--------------+---+---+---+---+---+---+---+---+ |Topic Filter | +------------+--------------+---+---+---+---+---+---+---+---+ | byte 1 |Length MSB (0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +------------+--------------+---+---+---+---+---+---+---+---+ | byte 2 |Length LSB (3)| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | +------------+--------------+---+---+---+---+---+---+---+---+ | byte 3 | 'a' (0x61) | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | +------------+--------------+---+---+---+---+---+---+---+---+ | byte 4 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | +------------+--------------+---+---+---+---+---+---+---+---+ | byte 5 | 'b' (0x62) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | +------------+--------------+---+---+---+---+---+---+---+---+ |Topic Filter | +------------+--------------+---+---+---+---+---+---+---+---+ | byte 6 |Length MSB (0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +------------+--------------+---+---+---+---+---+---+---+---+ | byte 7 |Length LSB (3)| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | +------------+--------------+---+---+---+---+---+---+---+---+ | byte 8 | 'c' (0x63) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | +------------+--------------+---+---+---+---+---+---+---+---+ | byte 9 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | +------------+--------------+---+---+---+---+---+---+---+---+ | byte 10 | 'd' (0x64) | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | +------------+--------------+---+---+---+---+---+---+---+---+ Figure 7.21 - UNSUBSCRIBE message payload non normative example 7.9 UNSUBACK UNSUBACK is MB's response of UNSUBSCRIBE. The fixed forehead is illustrated in Figure 7.22. +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 1| Message Type (9) | Reserved | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 2| Remaining Length (2) | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ Figure 7.22 - UNSUBSACK message fixed header Zhengjp, et al Expires December 22, 2017 [Page 24] Internet-Draft sipim-ext June 21, 2017 The value of Message Type is 9. The variable header is the message descriptor, as illustrated in Figure 7.23. +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 1| Message Identifier MSB | +-------------------------------------------------------+ | byte 2| Message Identifier LSB | +-------------------------------------------------------+ Figure 7.23 - UNSUBACK message variable header. 7.10 PINGREQ Heartbeat message, which the MUA sent to MB, only has fixed forehead. The fixed forehead is illustrated in Figure 7.24. +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 1| Message Type (10) | Reserved | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 2| Remaining Length (0) | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ Figure 7.24 - PINGREQ message fixed header Message Type: 10, represent the PINGREQ message; Flags: 0, reserved for future use; Remaining Length: 0, no variable header or the payload. 7.11 PINGRSEP The response of PINGREQ message, only has fixed forehead which is illustrated in Figure 7.25. Zhengjp, et al Expires December 22, 2017 [Page 25] Internet-Draft sipim-ext June 21, 2017 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 1| Message Type (11) | Reserved | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 2| Remaining Length (0) | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ Figure 7.25 - PINGRSEP message fixed header Except the Message Type, the description of message field is the same as PINGREQ. The value of Message Type is 11. 7.12 DISCONNECT The DISCONNECT message indicates that the MUA is disconnecting cleanly. It has fixed forehead only as illustrated in Figure 7.26 with no variable header or payload. +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 1| Message Type (3) | Reserved | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | byte 2| Remaining Length (0) | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +-------+-----+-----+-----+-----+-----+-----+-----+-----+ Figure 7.26 - DISCONNECT message fixed header 8 Compatibility Considerations This document extends a SIP method, IMX, where 'IM' means Instant Message and 'X' is the version number of the protocol. IMX is used for the registration of the SIP device which integrated with UA and MUA. The following is an example of the SIP REGISTER message where the IP of SIP server is 192.168.2.89 and the IP of SIP device is 192.168.2.161. REGISTER sip:192.168.2.89 SIP/2.0 Via: SIP/2.0/UDP 192.168.2.161:10586 Max-Forwards: 70 Zhengjp, et al Expires December 22, 2017 [Page 26] Internet-Draft sipim-ext June 21, 2017 From: ;tag=ca04c1391af3429491f2c4dfb e5e1b2e;epid=4f2e395931 To: Call-ID: da56b0fab5c54398b16c0d9f9c0ffcf2@192.168.2.161 CSeq: 1 REGISTER Contact: ;methods="INVITE, IM0, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER" User-Agent: RTC/1.2.4949 (BOL SIP Phone 1005) Event: registration Allow-Events: presence Content-Length: 0 Optionally, the response of SIP REGISTER message could carry a security token and the token is used for authenticating MUA of MB. MUA sends token to MB, MB validates the correctness of the token and thus complete the registration process of MUA. The following is an example of the response of SIP REGISTER message and the token can be encrypted, optionally. SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.2.161:10586 From: ;tag=ca04c1391af3429491f2c4dfb e5e1b2e;epid=4f2e395931 To: ;tag=-00834-14d0805b62bc026d Call-ID: da56b0fab5c54398b16c0d9f9c0ffcf2@192.168.2.161 CSeq: 1 REGISTER Allow: INVITE, IMX, ACK, OPTIONS, BYE, CANCEL, REGISTER, INFO, UPDATE, PRACK, REFER, SUBSCRIBE, NOTIFY, MESSAGE Contact: sip:192.168.2.161:10586 Content-Type: text/plain Content-Length: 32 Expires: 3600 6629fae49393a05397450978507c4ef1 The proposed scheme follows the extension of SIP protocol. Entity MUA provides backwards compatibility with SIP UA. The definition of MUA and MB meets the extension demand of SIP entity, furthermore, MUA and MB can interact with SIP logical entity normally. For example, when MUA requests authentication and registration, it sends registration message to application server firstly, and then application server would assign the most suitable MB for MUA and notify MUA if the message is matched. The message used in this process is in accordance with the method in SIP, which maintains compatibility about messages. And as a specific condition where the IP of SIP UA has changed, if connection between MUA and MB exists, UA does not need to register to SIP server. When a call arrives at the SIP server, server will send Zhengjp, et al Expires December 22, 2017 [Page 27] Internet-Draft sipim-ext June 21, 2017 calling instant message to MUA via MB and MUA parsers the message and wake up UA, then UA will register to server and process the call. 9 Security Considerations Although the message publisher and receiver are loosely-coupled while transmitting messages, the security can be ensured. Firstly, before subscribing or publishing, MUAs need to authenticate and register user authentication information with AS. In the process, the username and password must be encrypted to prevent interception of assertions. Secondly, the username and password stored in AS are also encrypted to prevent identity leakage. Thirdly, MB only sends messages of a Topic to the MUA which has been authenticated and subscribed the related Topic. The authentication and topic management belong to different entities, and it could avoid network attacks and was under firm security. When the IP address changes, current transmitting will stop and MUAs need to send a CONNECT message to MB to create a new connection. The message content should be encrypted by the encryption algorithm to ensure integrality and reliability of the message. 10 References 10.1 Normative Reference [IETF SIMPLE WG] International Business Machines Corporation (IBM), "MQTT Version 3.1.1", OASIS Standard, October 2014, http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt- v3.1.1-os.html. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, . [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, DOI 10.17487/RFC4976, September 2007, . [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol Zhengjp, et al Expires December 22, 2017 [Page 28] Internet-Draft sipim-ext June 21, 2017 (SIP) Extension for Instant Messaging", RFC 3428, DOI 10.17487/RFC3428, December 2002, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2 Informative References [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, . [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17487/RFC6121, March 2011, . [RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, . [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", RFC 3922, DOI 10.17487/RFC3922, October 2004, . [OASIS Standard MQTT] International Business Machines Corporation (IBM), "MQTT Version 3.1.1", OASIS Standard, October 2014, http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt- v3.1.1-os.html. Authors' Addresses Jianping Zheng China Mobile Communications Corporation China Mobile Research Institute Beijing, 100031 P. R. China Email: zhengjianping@chinamobile.com Yichuan Wu China Mobile Communications Corporation Zhengjp, et al Expires December 22, 2017 [Page 29] Internet-Draft sipim-ext June 21, 2017 China Mobile Research Institute Beijing, 100031 P. R. China Email: wuyichuan@chinamobile.com Weimin Lei Northeastern University School of Computer Science and Engineering Shenyang, China, 110819 P. R. China Email: leiweimin@mail.neu.edu.cn Wei Zhang Northeastern University School of Computer Science and Engineering Shenyang, China, 110819 P. R. China Email: zhangwei1@mail.neu.edu.cn Hao Li Northeastern University School of Computer Science and Engineering Shenyang, China, 110819 P. R. China Email: haoli2015@stumail.neu.edu.cn Zhengjp, et al Expires December 22, 2017 [Page 30]