Internet DRAFT - draft-zhengjp-sipcore-sipim-ext

draft-zhengjp-sipcore-sipim-ext



 



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: <sip:01062237496@192.168.2.89>;tag=ca04c1391af3429491f2c4dfb
      e5e1b2e;epid=4f2e395931
      To: <sip:01062237496@192.168.2.89>
      Call-ID: da56b0fab5c54398b16c0d9f9c0ffcf2@192.168.2.161
      CSeq: 1 REGISTER
      Contact: <sip:192.168.2.161:10586>;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: <sip:01062237496@192.168.2.89>;tag=ca04c1391af3429491f2c4dfb
      e5e1b2e;epid=4f2e395931
      To: <sip:01062237496@192.168.2.89>;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, <http://www.rfc-
              editor.org/info/rfc3261>.

   [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, <http://www.rfc-
              editor.org/info/rfc4975>.

   [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, <http://www.rfc-
              editor.org/info/rfc4976>.

   [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, <http://www.rfc-
              editor.org/info/rfc3428>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI
              10.17487/RFC2119, March 1997, <http://www.rfc-
              editor.org/info/rfc2119>.

10.2  Informative References
   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
              March 2011, <http://www.rfc-editor.org/info/rfc6120>.

   [RFC6121]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence",
              RFC 6121, DOI 10.17487/RFC6121, March 2011,
              <http://www.rfc-editor.org/info/rfc6121>.

   [RFC3860]  Peterson, J., "Common Profile for Instant Messaging
              (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004,
              <http://www.rfc-editor.org/info/rfc3860>.

   [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, <http://www.rfc-editor.org/info/rfc3922>.


   [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]