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]
