An Extension for SIP Instant Message Using Publish/Subscribe Mode
draft-zhengjp-sipcore-sipim-ext-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Jianping Zheng , Yichuan Wu , Weimin Lei , Wei Zhang , Hao Li | ||
| Last updated | 2016-12-23 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhengjp-sipcore-sipim-ext-00
Network Working Group Jianping Zheng
Internet-Draft Yichuan Wu
Intended Status: Experimental China Mobile Communications Corporation
Expires: June 24, 2017 Weimin Lei
Wei Zhang
Hao Li
Northeastern University
December 24, 2016
An Extension for SIP Instant Message Using Publish/Subscribe Mode
draft-zhengjp-sipcore-sipim-ext-00
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 instant message in session mode 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 June 24, 2017 [Page 1]
Internet-Draft sipim-ext December 24, 2016
This Internet-Draft will expire on June 22, 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 Description . . . . . . . . . . . . . . . . . 9
5.1 MUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1 Connection Maintenance . . . . . . . . . . . . . . . . 9
5.1.2 Topic Subscription and Message Publication . . . . . . 9
5.1.3 Message ID Generation . . . . . . . . . . . . . . . . . 9
5.1.4 Session Termination . . . . . . . . . . . . . . . . . . 9
5.2 MB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
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 Capacities . . . . . . . . . . . . . . . . . . . 10
6 Topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1 Setting Topic Rules . . . . . . . . . . . . . . . . . . . . 11
6.2 Organization of Topic . . . . . . . . . . . . . . . . . . . 11
6.3 Message Routing Based on Topic . . . . . . . . . . . . . . 12
7 Message Types . . . . . . . . . . . . . . . . . . . . . . . . . 12
Zhengjp, et al Expires June 24, 2017 [Page 2]
Internet-Draft sipim-ext December 24, 2016
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1.1 Fixed Header . . . . . . . . . . . . . . . . . . . . . 13
7.1.2 Variable Header . . . . . . . . . . . . . . . . . . . . 14
7.2 CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3 CONNACK . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.4 PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.5 PUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.6 SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.7 SUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.8 UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 22
7.9 UNSUBACK . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.10 PINGREQ . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.11 PINGRSEP . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.12 DISCONNECT . . . . . . . . . . . . . . . . . . . . . . . . 25
8 Compatibility Considerations . . . . . . . . . . . . . . . . . 25
9 Security Considerations . . . . . . . . . . . . . . . . . . . . 26
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1 Normative Reference . . . . . . . . . . . . . . . . . . . 26
10.2 Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Zhengjp, et al Expires June 24, 2017 [Page 3]
Internet-Draft sipim-ext December 24, 2016
1 Introduction
Instant message (IM) refers to a kind of real-time message transfer
service. The major 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 protocols, IM service can be implemented by some open
protocol suites, such as Extensible Messaging and Presence Protocol
(XMPP) (RFC 3920, RFC 3921)[1][2], Common Profile for Instant
Messaging (CPIM) (RFC 3860, RFC 3922)[3][4], SIP[7] for Instant
Messaging and Presence Leveraging Extensions (SIMPLE)[8]. And SIMPLE
is well-developed among these protocols 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, the increasing user requirement and the changing of usage
scenario, the existing SIMPLE framework limits the further
application and development of IM service which is mainly embodied as
follow.
1) Currently, store-and-forward mode turns to be the main
application patterns of message service, however, SIMPLE framework
still use Peer-to-Peer mode which is lagging behind the
development of instant message.
2) SIMPLE uses SIP and MSRP (The Message Session Relay Protocol)
as the core protocols, and provides three kinds of transmission
modes to achieve instant message: page mode, large message mode
and session mode. Page mode is suitable for transmitting short
messages by the way of SIP MESSAGE, in which the cost of message
header is more than message content in most case. Large message
mode adopts SIP and MSRP to transmit long messages. It firstly
creates a session between participants through SIP signaling and
transmits data through MSRP. As for session mode, it requires to
establish a SIP session and IM session, and keeps them for a
period of time. Message transmitting by SIP and MSRP is based on a
session, and the procedure of session establishing and terminating
add 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 reduce execution efficiency to some extent.
3) The main usage scenario of instant message is mobile Internet.
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
Zhengjp, et al Expires June 24, 2017 [Page 4]
Internet-Draft sipim-ext December 24, 2016
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 of terminal equipment 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[5] provides a group messaging
frame based on SIP and MSRP, which requires all participants
maintain a MSRP connection with MSRP Switch. However, maintaining
connection with the Switch over a length of time 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 group chatting in SIMPLE works in the peer-to-peer (P2P)
mode, and the routing problem of P2P have negative influence on
the extensibility and the promotion of execution efficiency. The
above issues have impeded the development of group chatting
service.
Although much of the functions can be realized through SIMPLE, there
are many disadvantages like low data transfer rate, network resource
waste and inefficient execution. Peer-to-peer mode limits the
development of IM service. In addition, instant messaging
applications based on SIMPLE or other related protocol suites are
primarily enterprise-oriented, which don'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 an agent of user, 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 reduce the system develop
difficulty.
2 Terminology
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[6].
Zhengjp, et al Expires June 24, 2017 [Page 5]
Internet-Draft sipim-ext December 24, 2016
3 Definitions
To extend SIP, this document defines:
1)MUA (Message User Agent): has functions of SIP User Agent. It is
responsible for producing, subscribing and publishing messages to
relevant Topic. At the same time, 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): deals the authentication, registration and
Topic subscribing request of MUA and manages user configuration
files. At the same time, it manages Topic, receives, stores and
forwards the messages and manages the group chat as well. It is
able to interact with other SIP entities to complete
authentication and registration for users.
3) Topic: is structured as a layered organization. Topic name is
the label 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 be globally unique.
4) Message Configuration Files: includes the users' basic
information and 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 framework implements the function of instant message based on
SIP and MSRP, but there are existing shortcomings in complex system
design, low execution efficiency and transmission efficiency and
unsuitable for large-scale usage scenario and so on. 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. And each message is associated with a related topic and
transmitted as the publish/subscribe mode.
Publish/subscribe mode, also called Observer mode, is a kind of
messages transport pattern which can be applied to store-and-forward
mode effectively. The messages are defined as the form of topic. The
users or MUAs generate topics according to some specific rules and
Zhengjp, et al Expires June 24, 2017 [Page 6]
Internet-Draft sipim-ext December 24, 2016
then publish to the MB. Users or MUAs can subscribe a topic from MB
and become relevant subscribers. When the message publisher publishes
the messages to topic, MB publishes the messages to all the relevant
subscribers. And the advantages of this solution are:
(1) Decoupling
a. Decoupling publisher from receiver
i. Space decoupling
When sending messages, the publisher and receiver don't need
to know the exist of each other, a relevant topic
subscriptions relationships will help the MB publish the
messages that the publisher published to MB to all 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 keeps the 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 messages.
(3) Stateless processing In the store-and-forward mode based on
publish/subscribe pattern, publishing the messages is asynchronous
with receiving the messages, so MB doesn't need to keep the state-
transition relationship for publishing and forwarding. Moreover,
this mode gets rid of the dependence of transaction and reduces
the cost.
Zhengjp, et al Expires June 24, 2017 [Page 7]
Internet-Draft sipim-ext December 24, 2016
(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 Publish/subscribe mode is more
suitable for current mobile Internet. The publisher and receiver
are loosely coupled, which makes it free from P2P connection and
reduces the network resource consumption. In addition, combining
publishing with forwarding, it lowers the cost of transmitting the
messages. Furthermore, MUA just needs to keep a connection with MB
and don't need to request registration frequently because of IP
address changes.
(6) Service openness Current SIMPLE frame has the session
negotiation through SIP/SDP, but the SDP is fit for audio and
video session not suitable for message service. For the purpose of
supporting the message service, SDP has to be extended, so it
brings more difficulty to realize. As for topic mode, users can
generate different Topics in terms of the requirement and the
other can subscribe the topics that they are interested in.
Therefore, this method enables the definition of service to be
more flexible from the standard and it is good for new message
service and service openness.
To support mobile Internet scenario, the communication between MUA
and MB breaks the limit that SIP is a test-based protocol. SIP is
an open protocol, which can be extended according to the
requirement of service. Mobile device is sensitive to traffic and
we must pay more attention to the efficiency of messages. So this
document defines a kind of lightweight and binary protocol for the
communication between MUA and MB. This protocol refers to the
design and message format of MQTT which will be described in more
detail in the subsequent sections.
The registration mechanism of SIP system is integrated. MUA and
MB's authentication and registration adopt this mechanism to ease
the work. 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, both of which will be
informed. What's more, this registration mechanism is beneficial
to load balancing.
Zhengjp, et al Expires June 24, 2017 [Page 8]
Internet-Draft sipim-ext December 24, 2016
5 Entities Behavior Description
5.1 MUA
The entity address, i.e., user ID, in network communication is
unique. The User ID is distributed by MB, but the username can be
defined by the user himself, such as Email address, SIP URL and
telephone number.
5.1.1 Connection Maintenance
A TCP connection needs to be established between MUA and MB. The
heartbeat mechanism with PINGREQ and PINGRESP messages is employed to
maintain the long-lived connection between client and MB.
Communication among MUAs is based on Topic. This topic-based
transport pattern gets a loose coupling between the publisher and
receiver and achieves one-to-one message service and group message
service easily. On the other hand, it's also helpful to make the user
and terminal decoupled and support multi-terminal mode easily.
5.1.2 Topic Subscription and Message Publication
By sending SUBSCRIBE message to MB, MUA subscribes the Topics which
it is interested in. About publishing, MUA adopts PUBLISH message
which includes the Topic information and message content.
There are some differences in the receiving and sending different
types of messages. For text message, MUA sends data to MB directly,
and then MB sends it to MUA who has subscribed this Topic before. For
multimedia message such as picture, document and so on, the
transmission mode is a little complex. Referring to the offline file,
The MUA of sender sends data to specialized multimedia data server
and the server returns relevant URL link. Then MUA puts the URL link
in the payload of PUBLISH message and send to 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.3 Message ID Generation
MUA needs to generate a new and unique message ID when constructing
some messages, such as PUBLISH (in cases where QoS > 0), SUBSCRIBE,
and UNSUBSCRIBE. The message ID is used to associate response
messages with their corresponding request messages and thus ensure
the transmission reliability.
5.1.4 Session Termination
Zhengjp, et al Expires June 24, 2017 [Page 9]
Internet-Draft sipim-ext December 24, 2016
When terminating session for some reason, the MUA will send DISCONNET
message to MB and turn to offline state itself.
5.2 MB
MB is responsible for complicated processing logic. It manages the
forwarding of messages and the storage of users' offline messages and
buddy list information.
5.2.1 Request Authentication
When MUA sends CONNECT message to request connection, MB must
authenticate the request by comparing the Token value in CONNECT
message with the token in uniform authentication platform. If the
comparison result is equal, MB will pre-subscribe the Topics of
user's buddy list and relevant Topics of user's behavior. If failed,
MB will reject to the CONNECT message.
5.2.2 Connection Maintenance
MB maintains the connection with client and replies to the MUA's
heartbeat request. When beyond the keep-alive time expires but no
data packet from MUA is received, the MB will mark the MUA as
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. For example, when receiving a
SUBSCRIBE message, MB will send a SUBACK message as a response.
According to whether receiving SUBACK message or not, MUA will know
whether subscribe successfully or not.
5.2.4 Processing Offline Messages
For some reason, MUA has disconnected MB and its user state is
offline. At that time, if someone sends messages to it, the MB will
be responsible for receiving and storing these offline messages until
it is online again. What's more, the MB will push these offline
messages to MUA as soon as it is online.
5.2.5 Other Capacities
MB has some other capacities:
Semantic Parsing: MB is responsible for parsing the Topic semantic
Zhengjp, et al Expires June 24, 2017 [Page 10]
Internet-Draft sipim-ext December 24, 2016
and determining the Topic behavior according to the Topic information
of MUA. For example, by parsing the user ID included in Topic, MB
finds the receiver of messages and sends the messages to him.
Message Routing: when MUA publishes messages, if the destination sets
are not null, MB will forward the messages to the destination, i.e.,
the MB or the MUA who is interested in this Topic.
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. On the
contrast, if a Topic is set "write", its user will only have the
permission of sending. (definition rules: username topic rw)
State Presenting: all the states are presented by user presence. The
function of 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.
Broker to Broker: it is the connection between two MBs and is
considered as the communicating extension between client and server.
6 Topic
6.1 Setting Topic Rules
Topic can be considered as the identification of message data. As for
receiving messages, the MUA of receiver needs to subscribe the Topic
of interest to MB. To different message types, MB's processing logic
is different. So this document defines that the first part of Topic
is the service profile identifiers which is used to distinguish
different message types. For example, the one-to-one messages'
service profile identifier is defined as 110 while the group
messages' is 200. The one-to-one messages' Topic is /100/UID while
the group messages' is /200/GID. For one-to-one messages service, MUA
subscribes the Topic it is interested in for itself, while for group
messages service, all the users in the group subscribe the same
Topic.
6.2 Organization of Topic
The organization of Topic is related to the user behavior. 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.
Zhengjp, et al Expires June 24, 2017 [Page 11]
Internet-Draft sipim-ext December 24, 2016
Using adding friends as an example, when Alice wants Bob to become a
friend of hers, she needs to send requesting to the Topic of Bob's
adding friends, i.e., Bob@example.com/friend/new. Then Bob sends
response to Alice's Topic, i.e., Alice@example.com/friend/new. If Bob
agree with this requesting, Alice will send the information both of
them to relevant Topic and at last they will communicate with each
other in this Topic.
6.3 Message Routing Based on Topic
MB achieves the functions of filtering and routing based on Topic. In
Publish/subscribe message system, the publisher publishes the
messages to MB and the subscriber subscribes the Topic which it is
interested in through MB. And MB stores and forwards these messages.
When a client subscribes a Topic, the MB at which the client located
will notify all the other MBs that the Topic has been subscribed by
it.
When a client publishes a message, the MB located will route this
message to the MB which subscribed the Topic and the latter message
will be routed to the client.
The message routing based on Topic supports the user-defined Topic,
which requires the user to register the Topic. This way is beneficial
to service opening and diversity.
7 Message Types
7.1 Overview
Referring to MQTT protocol [9], this scheme defines 11 kinds of
message types expressed in 4 bits. These 11 kinds of messages types
are CONNECT, CONNACK, PUBLISH, PUBACK, SUBSCRIBE, SUBACK,
UNSUBSCRIBE, UNSUBACK, PINGREQ, PINGRESP and DISCONNECT. They can be
divided into 4 categories according to different functions:
1) Connection Class: CONNECT (value =1), and MUA sends it to MB to
request connection. CONNACK (value =2), and MB sends it to MUA as
the response of CONNECT. DISCONNECT (value =14), and MUA sends it
MB to request disconnection.
2) Keep-alive Class: PINGREQ (value =12), and MUA sends it to MB
to ask whether the connection still exist. PINGRESP (value =13),
and MB sends it to MUA in response to PINGREQ.
3) Subscription Class: SUBSCRIBE (value =8), and MUA sends it to
Zhengjp, et al Expires June 24, 2017 [Page 12]
Internet-Draft sipim-ext December 24, 2016
MB to subscribe Topic. SUBACK (value =9), and MB sends it to MUA
in response to subscribe. UNSUBSCRIBE (value =10), and MUA sends
it to MB to cancel the SUBSCRIBE. UNSUBACK (value =11), and MB
sends it to MUA in response to UNSUBSCRIBE.
4) Publishing Class: PUBLISH (value =3), and MUA and MB can send
it to each other to publish messages in a Topic. PUBACK (value
=4), and it is the response of PUBLISH.
The message contains 3 components: Fixed header, Variable header and
Payload as illustrated in Figure 7.1.
+-------------------------------+
| Fixed header |
+-------------------------------+
| Variable header |
+-------------------------------+
| Payload |
+-------------------------------+
Figure 7.1 - Message structure
7.1.1 Fixed Header
Each message contains a fixed header. Figure 7.2 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.2 - 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 fixed header can be extended to four
bytes at most.
Zhengjp, et al Expires June 24, 2017 [Page 13]
Internet-Draft sipim-ext December 24, 2016
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.3.
+-----------------------------------+
|Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
+-----------------------------------+
|byte 1 | Message Identifier MSB |
+-----------------------------------+
|byte 2 | Message Identifier LSB |
+-----------------------------------+
Figure 7.3 - Message Identifier bytes
Message Identifier: two bytes, non-zero, unique identification of a
message.
This document refers to MQTT protocol to define the message types,
however, not using the message header whose QoS is 2, this
specification defines 11 kinds of message types, including CONNECT,
CONNACK, PUBLISH, PUBACK, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK,
PINGREQ, PINGRES and DISCONNECT.
7.2 CONNECT
CONNECT, requesting connection, the fixed header as illustrated in
Figure 7.4.
+----------------------------------------+
|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.4 - CONNECT message fixed header
Message Type: 1, represent the CONNECT message;
Flags: 0, reserved for future use;
Zhengjp, et al Expires June 24, 2017 [Page 14]
Internet-Draft sipim-ext December 24, 2016
Remaining Length: uncertain, depend on the data in the variable
header and the payload.
The variable header carries the protocol version information as
illustrated in Figure 7.5. The protocol version is a UTF-8 encoded
string that represents the protocol version "IM01".
+------------------------------------------------------+
| | 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 | 1 | 0 | 0 |
+------------------------------------------------------+
|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 |
+------------------------------------------------------+
|byte 6 | '1' | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 |
+------------------------------------------------------+
Figure 7.5 - 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.6.
Zhengjp, et al Expires June 24, 2017 [Page 15]
Internet-Draft sipim-ext December 24, 2016
+--------------------------------------+
|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.6 - CONNACK message fixed header
Message Type: 2, represent the CONNACK message;
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.7.
+----------------------------------------------------------+
| | 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.7 - 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
Zhengjp, et al Expires June 24, 2017 [Page 16]
Internet-Draft sipim-ext December 24, 2016
PUBLISH, sent from MUA to MB or from MB to MUA to transport an
application message, the fixed header as illustrated in Figure 7.8.
Typically,
DUM = Duplicate delivery of a PUBLISH message;
QoS = PUBLISH quality of service;
RETAIN = PUBLISH retain flag.
+------------------------------------------------------------+
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+------------------------------------------------------------+
| byte 1 | Message Type (3) |DUM flag| QoS level |RETAIN|
+------------------------------------------------------------+
| | 0 | 0 | 1 | 1 | X | X | X | X |
+------------------------------------------------------------+
| byte 2 | Remaining Length |
+------------------------------------------------------------+
Figure 7.8 - PUBLISH message fixed header
Message Type: 3, represent the PUBLISH message;
DUM flag: 0 indicates that it isn't a retransmission message and 1
indicates it is.
QoS level: indicate the level of assurance for delivery of an
Application Message.
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.9 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 June 24, 2017 [Page 17]
Internet-Draft sipim-ext December 24, 2016
+----------------------------------------------------------------------+
| |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.9 - PUBLISH message variable header non normative example
Topic Name: indicate which Topic is going to send data;
Message Identifier: is only present in PUBLISH message where the QoS
level is 1 or 2.
Payload in PUBLISH carries the data which is described in Topic,
i.e., the message content.
7.5 PUBACK If QoS is 1 in PUBLISH, PUBACK will as the response and
expresses that the message is received successfully by Broker. The
fixed forehead is illustrated in Figure 7.10.
+---------------------------------------+
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+---------------------------------------+
| byte 1|Message Type(4)| Reserved |
+---------------------------------------+
| | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 |
+---------------------------------------+
| byte 2| Remaining Length (2) |
+---------------------------------------+
| | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
+---------------------------------------+
Figure 7.10 - PUBACK message fixed header
Zhengjp, et al Expires June 24, 2017 [Page 18]
Internet-Draft sipim-ext December 24, 2016
Except the Message Type, the description of message field is the same
as CONNACK. The value of Message Type is 4.
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.11 - 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.12.
+---------------------------------------+
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+---------------------------------------+
| byte 1|Message Type(8)| Reserved |
+---------------------------------------+
| | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
+---------------------------------------+
| byte 2| Remaining Length |
+---------------------------------------+
Figure 7.12 - SUBSCRIBE message fixed header
Message Type: 8, 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.13 shows a variable header with Packet
Identifier set to 10.
Zhengjp, et al Expires June 24, 2017 [Page 19]
Internet-Draft sipim-ext December 24, 2016
+------------------------------------------------------------------+
| | 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.13 - SUBSCRIBE message variable header
The payload of a SUBSCRIBE message contains a list of Topic Filters
indicating the Topics to which the Client wants to subscribe. The
Topic Filters in a SUBSCRIBE message payload MUST be UTF-8 encoded
strings. The payload is illustrated in Figure 7.14.
+-------------------------------------------+
|Description| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-------------------------------------------+
|Topic Filter |
+-------------------------------------------+
|byte 1 |Length MSB |
+-------------------------------------------+
|byte 2 |Length LSB |
+-------------------------------------------+
|bytes 3..N |Topic Filter |
+-------------------------------------------+
|Requested QoS |
+-------------------------------------------+
| | Reserved | QoS |
+-------------------------------------------+
|byte N+1 | 0 | 0 | 0 | 0 | 0 | 0 | X | X |
+-------------------------------------------+
Figure 7.14 - SUBSCRIBE message payload
Typically, the upper 6 bits of the Requested QoS byte are not used in
the current version of the protocol. They are reserved for future
use. The MB must treat a SUBSCRIBE packet as malformed and close the
network connection if any of Reserved bits in the payload are non-
zero, or QoS is not 0, 1 or 2.
7.7 SUBACK
SUBACK is MB's response of SUBSCRIBE. The fixed forehead is
illustrated in Figure 7.15.
Zhengjp, et al Expires June 24, 2017 [Page 20]
Internet-Draft sipim-ext December 24, 2016
+-------------------------------------------------------+
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-------------------------------------------------------+
| byte 1| MQTT Message Type (9) | Reserved |
+-------------------------------------------------------+
| | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
+-------------------------------------------------------+
| byte 2| Remaining Length |
+-------------------------------------------------------+
Figure 7.15 - SUBSCRIBE message fixed header
Except the Message Type, the description of message field is the same
as PUBLISH. The value of Message Type is 9.
The variable header contains the Message Identifier from the
SUBSCRIBE Packet that is being acknowledged. Figure 7.16 below
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.16 - 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.17 below 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.17 - SUBSCRIBE message payload
Allowed return codes:
Zhengjp, et al Expires June 24, 2017 [Page 21]
Internet-Draft sipim-ext December 24, 2016
0x00 - Success - Maximum QoS 0 ;
0x01 - Success - Maximum QoS 1 ;
0x02 - Success - Maximum QoS 2 ;
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.18.
+-------------------------------------------------------+
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-------------------------------------------------------+
| byte 1| Message Type (10) | Reserved |
+-------------------------------------------------------+
| | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 0 |
+-------------------------------------------------------+
| byte 2| Remaining Length |
+-------------------------------------------------------+
Figure 7.18 - 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 10.
The variable header is the message descriptor, as illustrated in
Figure 7.19.
+-------------------------------------------------------+
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-------------------------------------------------------+
| byte 1| Message Identifier MSB |
+-------------------------------------------------------+
| byte 2| Message Identifier LSB |
+-------------------------------------------------------+
Figure 7.19 - UNSUBSCRIBE message variable header
The payload for the UNSUBSCRIBE message contains the list of Topic
Filters that the Client wishes to unsubscribe from. The Topic Filters
in an UNSUBSCRIBE message must be UTF-8 encoded strings. Figure 7.20
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 June 24, 2017 [Page 22]
Internet-Draft sipim-ext December 24, 2016
+-----------------------------------------------------------+
| | 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.20 - UNSUBSCRIBE message payload non normative example
7.9 UNSUBACK
UNSUBACK is MB's response of UNSUBSCRIBE. The fixed forehead is
illustrated in Figure 7.21.
+-------------------------------------------------------+
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-------------------------------------------------------+
| byte 1| Message Type (11) | Reserved |
+-------------------------------------------------------+
| | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 |
+-------------------------------------------------------+
| byte 2| Remaining Length (2) |
+-------------------------------------------------------+
| | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
+-------------------------------------------------------+
Figure 7.21 - UNSUBSACK message fixed header
Zhengjp, et al Expires June 24, 2017 [Page 23]
Internet-Draft sipim-ext December 24, 2016
Except the Message Type, the description of message field is the same
as CONNACK. The value of Message Type is 11.
The variable header is the message descriptor, as illustrated in
Figure.
+-------------------------------------------------------+
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-------------------------------------------------------+
| byte 1| Message Identifier MSB |
+-------------------------------------------------------+
| byte 2| Message Identifier LSB |
+-------------------------------------------------------+
Figure 7.22 - UNSUBACK message variable header.
7.10 PINGREQ
Heartbeat packet, which the client sent to MB, only has fixed
forehead. The fixed forehead is illustrated in Figure 7.23.
+-------------------------------------------------------+
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-------------------------------------------------------+
| byte 1| Message Type (12) | Reserved |
+-------------------------------------------------------+
| | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 |
+-------------------------------------------------------+
| byte 2| Remaining Length (0) |
+-------------------------------------------------------+
| | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+-------------------------------------------------------+
Figure 7.23 - PINGREQ message fixed header
Message Type: 12, 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.24.
Zhengjp, et al Expires June 24, 2017 [Page 24]
Internet-Draft sipim-ext December 24, 2016
+-------------------------------------------------------+
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-------------------------------------------------------+
| byte 1| Message Type (13) | Reserved |
+-------------------------------------------------------+
| | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 0 |
+-------------------------------------------------------+
| byte 2| Remaining Length (0) |
+-------------------------------------------------------+
| | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+-------------------------------------------------------+
Figure 7.24 - PINGRSEP message fixed header
Except the Message Type, the description of message field is the same
as PINGREQ. The value of Message Type is 13.
7.12 DISCONNECT
The DISCONNECT message indicates that the MUA is disconnecting
cleanly. It has fixed forehead only as illustrated in Figure 7.25
with no variable header or payload.
+-------------------------------------------------------+
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+-------------------------------------------------------+
| byte 1| Message Type (14) | Reserved |
+-------------------------------------------------------+
| | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
+-------------------------------------------------------+
| byte 2| Remaining Length (0) |
+-------------------------------------------------------+
| | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+-------------------------------------------------------+
Figure 7.25 - DISCONNECT message fixed header
Except the Message Type, the description of message field is the same
as PINGREQ. The value of Message Type is 14.
8 Compatibility Considerations
The proposed scheme follows the extension logic of SIP protocol.
Newly defined entity MUA provides backwards compatibility with SIP UA
and has the same functions as 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
Zhengjp, et al Expires June 24, 2017 [Page 25]
Internet-Draft sipim-ext December 24, 2016
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.
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 belongs 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
[1] Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Core", RFC 6120, March 2011.
[2] Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence", RFC 6121, March 2011.
[3] Peterson, J., "Common Profile for Instant Messaging (CPIM)",
RFC3860, August 2004.
[4] Saint-Andre, P., "Mapping Extensible Messaging and Presence
Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", RFC
3922, October 2004.
[5] Niemi, A., Garcia-Martion, M., and G. Sandbakken, "Multi-party
Chat Using the Message Session Relay Protocol (MSRP)", RFC7701,
December 2015.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
10.2 Informative References
Zhengjp, et al Expires June 24, 2017 [Page 26]
Internet-Draft sipim-ext December 24, 2016
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session
Initiation Protocol", RFC 3261, June 2002.
[8] Rosenberg, J., "SIMPLE Made Simple: An Overview of the IETF
Specifications for Instant Messaging and Presence Using the Session
Initiation Protocol (SIP)", RFC6914, April 2013.
[9] International Business Machines Corporation (IBM), "MQTT V3.1
Protocol Specification",
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-
v3rl.html, August 2010.
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
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
Zhengjp, et al Expires June 24, 2017 [Page 27]
Internet-Draft sipim-ext December 24, 2016
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 June 24, 2017 [Page 28]