idnits 2.17.1 draft-zhengjp-sipcore-sipim-ext-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 129 has weird spacing: '...ith the devel...' == Line 192 has weird spacing: '...esource and c...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 21, 2017) is 2501 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1235, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jianping Zheng 3 Internet-Draft Yichuan Wu 4 Intended Status: Experimental China Mobile Communications Corporation 5 Expires: December 22, 2017 Weimin Lei 6 Wei Zhang 7 Hao Li 8 Northeastern University 9 June 21, 2017 11 An Extension for SIP Instant Message Using Publish/Subscribe Mode 12 draft-zhengjp-sipcore-sipim-ext-01 14 Abstract 16 SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) 17 is a protocol suite for instant messaging (IM) service, but it is 18 inefficient in processing session-mode instant message due to its 19 complex signaling processes and heavy header overheads, which makes 20 it difficult to meet the QoE (quality of experience) requirement, 21 especially in the usage scenario of mobile Internet and other traffic 22 sensitive networks. 24 This document describes an alternative Session Initiation Protocol 25 (SIP) extension for instant messaging service. The extension uses the 26 publish-subscribe mode to simplify signaling procedures and 27 introduces message user agent (MUA) to publish and receive message, 28 and message broker (MB) as an intermediary to exchange messages 29 between MUAs. Message is tagged with a topic, and the lightweight 30 message format is more suitable for traffic sensitive networks. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as 40 Internet-Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 08, 2017. 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/1id-abstracts.html 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. This document is subject to 58 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 59 Documents (http://trustee.ietf.org/license-info) in effect on the 60 date of publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5 Entities Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 74 5.1 MUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 5.1.1 User Identity(ID) and User Name . . . . . . . . . . . . 8 76 5.1.2 Connection Maintenance . . . . . . . . . . . . . . . . 9 77 5.1.3 Topic Subscription and Message Publication . . . . . . 9 78 5.1.4 Message ID Generation . . . . . . . . . . . . . . . . . 9 79 5.1.5 Session Termination . . . . . . . . . . . . . . . . . . 9 80 5.2 MB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 5.2.1 Request Authentication . . . . . . . . . . . . . . . . 10 82 5.2.2 Connection Maintenance . . . . . . . . . . . . . . . . 10 83 5.2.3 Sending Responses . . . . . . . . . . . . . . . . . . . 10 84 5.2.4 Processing Offline Messages . . . . . . . . . . . . . . 10 85 5.2.5 Other Features . . . . . . . . . . . . . . . . . . . . 10 86 6 Topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 6.1 Topic Policy . . . . . . . . . . . . . . . . . . . . . . . 11 88 6.2 Organization of Topic . . . . . . . . . . . . . . . . . . . 11 89 6.3 Topic-based Message Routing . . . . . . . . . . . . . . . . 12 91 7 Message Formats . . . . . . . . . . . . . . . . . . . . . . . . 12 92 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 7.1.1 Fixed Header . . . . . . . . . . . . . . . . . . . . . 14 94 7.1.2 Variable Header . . . . . . . . . . . . . . . . . . . . 14 95 7.2 CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 7.3 CONNACK . . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 7.4 PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 7.5 PUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 7.6 SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 7.7 SUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 7.8 UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 22 102 7.9 UNSUBACK . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 7.10 PINGREQ . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 7.11 PINGRSEP . . . . . . . . . . . . . . . . . . . . . . . . . 25 105 7.12 DISCONNECT . . . . . . . . . . . . . . . . . . . . . . . . 26 106 8 Compatibility Considerations . . . . . . . . . . . . . . . . . 26 107 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 28 108 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 109 10.1 Normative Reference . . . . . . . . . . . . . . . . . . . 28 110 10.2 Informative References . . . . . . . . . . . . . . . . . . 29 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 113 1 Introduction Instant messaging (IM) services enable real-time text 114 and multimedia exchange and online presence awareness. The main 115 service characteristics of IM include various media type (text, 116 audio, video, picture, emoji, etc.) and high interactivity (group 117 chat, online game etc.). Besides some proprietary IM protocols used 118 by software deployed today, IM service can be implemented by some 119 open standards, such as Extensible Messaging and Presence Protocol 120 (XMPP)[RFC6120][RFC6121], Common Profile for Instant Messaging 121 (CPIM)[RFC3860][RFC3922], SIP for Instant Messaging and Presence 122 Leveraging Extensions (SIMPLE)(which consists of a series of 123 standards)[IETF SIMPLE WG]. And SIMPLE is comparatively complete 124 among these standards and has been adopted by many vendors as the 125 standard of instant messaging applications. 127 SIMPLE is a SIP-based protocol suite, which has been applied in many 128 applications, such as the presence and the instant messaging. 129 However, with the development of the multimedia and related storage 130 technology, and the changing requirements of users, the existing 131 SIMPLE framework has limited the further development of IM service, 132 which is discussed as follows. 134 1) SIMPLE uses SIP[RFC3261] and MSRP (The Message Session Relay 135 Protocol)[RFC4975][RFC4976] as the core protocols, and defines two 136 modes of instant messaging: page mode and session mode. Page mode 137 is suitable for transmitting short messages by the way of SIP 138 MESSAGE[RFC3428], but compared with the message content, the 139 message header overhead is heavy in most cases, which has 140 decreased the overall transmission efficiency. Session mode adopts 141 SIP and MSRP to transmit long messages or files. It firstly 142 establishes a session between participants by SIP signaling and 143 uses MSRP to transmits messages. However, the procedure of session 144 establishing and terminating is relatively complex and will 145 introduce extra overhead, and thus affects the overall efficiency 146 of message transfer. MSRP is a text-based connection oriented 147 protocol and the extra overhead of the message is big, which will 148 also lower execution efficiency to some extent. 150 2) For IM service, store-and-forward mode turns to be the main 151 application patterns, however, SIMPLE framework still uses Peer- 152 to-Peer mode in which messages can be transmitted between 153 participants directly, but when the communication is interrupted, 154 the connection between participants should be re-built and the 155 message being transferred should be re-transmitted between sender 156 and receiver. Store-and-forward mode adopts a middleware to 157 receive and forward messages, in which the process of message 158 sending and receiving is asynchronous and the middleware assures 159 reliable message delivery. 161 3) The main usage scenario of instant message is mobile Internet 162 and mobile phones are one of the most important communication 163 devices available these days. In mobile Internet, the IP address 164 of the mobile device is time-varying as it moves. To provide the 165 addressability of the endpoint, the mobile device must register to 166 server constantly when its address changes. For a SIP-based 167 instant message application, the vibrating registration which 168 caused by the changing IP address will cause a huge overhead of 169 traffic and power. The mobile device is sensitive to the traffic 170 and power consumption in mobile Internet, and the vibrating 171 registration will decrease the quality of experience of users. 173 4) Group chatting is an important feature of IM service, and the 174 implementation of group chatting by SIMPLE uses the SIP Conference 175 service for references. RFC7701 provides a group messaging frame 176 based on SIP and MSRP, which requires all participants maintain a 177 MSRP connection with MSRP Switch. However, long-time connection 178 with the Switch would cause a great waste of network resources 179 when there is no traffic transfer and the re-establishment of the 180 connection will waste more when a short message needs to be 181 transmitted. This method will cause a higher traffic and power 182 consumption and thus reduce service experience of user. 184 5) The scaling problem is also a severe problem for SIMPLE-based 185 IM, especially relevant considering the explosive growth in sales 186 of users. For a large-scale network, the management and process of 187 message can become very complex, which will affect the promotion 188 of execution efficiency and resource utilization. 190 Much of the functions can be realized through SIMPLE, but the 191 disadvantages, such as high traffic demand, inefficient execution, 192 waste of network resource and complicated functionality extension, 193 have impeded the development of SIP-based IM service. In addition, 194 instant messaging applications based on SIMPLE or other related 195 protocol suites are primarily enterprise-oriented, which doesn't 196 apply to use on a large scale. To solve these problems, this document 197 extends the current SIP, adding two kinds of logical entities named 198 Message User Agent (MUA) and Message Broker (MB). MUA is a user 199 agent, which is responsible for publishing and receiving messages, 200 creating, modifying and deleting a group. MB is in charge of message 201 receiving, storing and forwarding, and in the meanwhile it manages 202 the group. Each message is associated with a related topic and the 203 transfer method is based on the publish/subscribe mode which 204 decouples publisher and receiver dependencies, and reduces the system 205 extension problem. 207 2 Terminology 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 209 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 210 this document are to be interpreted as described in RFC 2119. 212 3 Definitions 214 To extend SIP, this document defines: 216 1)MUA (Message User Agent): MUA can be authenticated and 217 registered with the SIP Server, which is exactly the same as the 218 SIP UA, then MUA must register with the MB and maintain a TCP 219 connection with MB. MUA is responsible for producing, subscribing 220 and publishing messages to relevant Topic. It receives messages 221 from MB, manages the users' configuration files and participates 222 in creation, modification and deletion of a group. It's also used 223 for authentication and register of user. 225 2) MB (Message Broker): MB deals with the authentication, 226 registration and Topic subscribing request from MUA and manages 227 user configuration files. And it manages Topic, receives, stores 228 and forwards the messages, and manages the group chat. It 229 interacts with other SIP entities to complete authentication and 230 registration for users. 232 3) Topic: Topic is structured as a layered organization. Topic 233 name is the tag of a kind of or a set of instant message. It is 234 generated in MUA, and published to MB, and finally stored in MB. 235 MUA updates the message contents of a Topic, and MB will match the 236 subscribers of the Topic and push the message to those 237 subscribers. And the group chatting topic is generated in MB and 238 must be globally unique. 240 4) Message Configuration Files: Message Configuration Files 241 include the users' basic information, messaging strategy and group 242 information. When the users start registering, they will upload 243 the configuration documents to MB and MB will complete the 244 subscription of relevant Topic for the users according to it. 246 4 Overview SIMPLE is an open instant messaging (IM) and presence 247 protocol suite based on SIP and MSRP, but its complex signaling 248 processes and heavy header overheads has decreased the execution 249 efficiency, which has affected the user experience. To solve these 250 problems, this document introduces two logical entities: MUA and MB, 251 which are responsible for SIP message service. This scheme uses 252 store-and-forward mode to transmit messages instead of the peer-to- 253 peer mode. The store-and-forward mode used in the proposed document 254 is publish/subscribe mode. Publish/subscribe mode, also called 255 Observer mode, is a kind of messages transport pattern which can be 256 applied to store-and-forward mode effectively. Each message is 257 associated with a related topic. MUAs generate topics according to 258 some specific rules and then publish to the MB. MUAs subscribe a 259 topic from MB and become relevant subscribers. When the message 260 sender publishes the messages to topic, MB publishes the messages to 261 all the relevant subscribers. And the advantages of the proposed 262 solution are discussed as follows: 264 (1) Decoupling 265 a. Decoupling publisher from receiver 267 i. Space decoupling 269 When sending messages, the publisher doesn't need to know 270 whether the receiver is online, a relevant topic 271 subscriptions relationships will help the MB publish the 272 messages that the publisher published to the relevant 273 subscribers. 275 ii. Time decoupling 277 The publisher and receiver don't need to establish 278 connection simultaneously to assure the immediacy and 279 efficiency. 281 iii. Synchronization decoupling 283 The publisher doesn't need to establish the synchronization 284 relationship with the receiver. It publishes the messages to 285 MB and the receiver receives in an asynchronous way, i.e., 286 MUA-to-MB, MB-to-MUA, by keeping a connection with MB. 288 b. Decoupling the user from terminal device For multi-terminal 289 user, the user just maintains a weak relation with the terminal 290 device. The terminal device keeps the synchronization 291 relationship with MB and subscribes topic independently. 293 (2) Reducing the complexity of implementation All the messages 294 including one-to-one messages, one-to-many messages and group 295 messages can be defined as the form of topic and transmitted as 296 the publish/subscribe mode. This method makes different kinds of 297 messages have the approximate cost. Furthermore, it reduces the 298 implementation complexity of group chatting. 300 (3) Stateless processing In the store-and-forward mode based on 301 publish/subscribe pattern, message publishing is asynchronous with 302 message receiving, so MB doesn't need to maintain the state- 303 transition relationship for message publishing and forwarding. 305 Moreover, this mode gets rid of the dependence of transaction and 306 reduces the cost. 308 (4) Expansibility Publish/subscribe mode achieves distributed 309 architecture, parallel operations, message buffer and tree routing 310 or mesh routing. Therefore, it could achieve a high expansibility, 311 and suit for the large-scale usage scenario and improve the 312 insufficiency caused by the tightly coupled and data-center 313 service. 315 (5) Environmental suitability 317 In publish/subscribe mode, publishers and receivers are loosely 318 coupled, and each of them only needs to keep a connection with MB, 319 which supports the mobility, frequent disconnection of mobile 320 Internet. 322 (6) Service openness The extension of a new application or 323 function in SIMPLE is complex due to the tedious process of the 324 extension of SIP/SDP, but in topic mode, the application can be 325 realized by generating different Topics in terms of the 326 requirement and the others can subscribe the topics that they are 327 interested in. Therefore, this method enables the definition and 328 realization of service in a more flexible way and supports the 329 openness of service. 331 The two new entities (i.e., MUA and MB, which will be described in 332 more detail in the subsequent sections) adopt the binary-based 333 message format refers to the MQTT (Message Queuing Telemetry 334 Transport)[OASIS Standard MQTT] to better support the mobile 335 Internet scenario. MB needs to register to the Proxy or the 336 application server (AS) in charge of message service for the 337 purpose of legality. The registration mechanism of MUA is similar 338 with SIP UA but not the same, the difference is that MUA is 339 responsible for message service and needs to request 340 authentication to Proxy or AS. Proxy or AS would assign a MB for 341 MUA based on the current system load. 343 5 Entities Behavior 345 5.1 MUA 347 5.1.1 User Identity(ID) and User Name 349 User ID is an identity that is provided by MB to uniquely represent a 350 MUA and is transparent to the user, and is used for authentication 351 and message transmission. User can use a unique user name by himself 352 and the user name is associated with the User ID. 354 5.1.2 Connection Maintenance 356 A TCP connection needs to be established between MUA and MB. And a 357 heartbeat mechanism is employed to maintain a long-lived connection 358 between client(MUA) and MB. Communication among MUAs is associated 359 with Topic. This topic-based transport pattern provides a loose 360 coupling relationship between the publisher and receiver, and makes 361 the implementation of one-to-one message service and group message 362 service easier. And it's also helpful to decouple the user and 363 terminal and support multi-terminal mode easily. 365 5.1.3 Topic Subscription and Message Publication 367 MUA subscribes to the topics it is interested in by sending a 368 subscription message to MB. And the message should include the 369 interested topics. When a message is published to a topic, MB will 370 match the subscribers and publish the message to subscribers, and the 371 published message includes the topic information and message content. 373 Different types of message have different transmission strategies. 374 For plain text message, MUA sends data to MB directly, and then MB 375 sends it to MUA who has subscribed this Topic. For multimedia message 376 such as pictures, files and so on or the text message is lengthy, 377 sender sends data to specialized multimedia server and the server 378 returns relevant URL link. Then MUA puts the URL link in the payload 379 of message and publishes to an associative topic stored in MB. When 380 MB receives, it sends the message to all relevant subscribers. 381 Finally, the subscribers will parse the message to get the URL and 382 downloads multimedia data from the multimedia data server. 384 5.1.4 Message ID Generation 386 MUA needs to generate a local unique message ID for a new message. 387 The message ID is used to associate response messages with their 388 corresponding request messages and thus ensures the transmission 389 reliability. 391 5.1.5 Session Termination 393 When terminating session for some reason, the MUA will send a message 394 to MB and aborts the connection with MB. 396 5.2 MB 398 MB is responsible for the authentication of MUA, connection 399 management, message forwarding and the storage of users' offline 400 messages and message configuration file. 402 5.2.1 Request Authentication 404 When MUA sends a message to request connection, MB must authenticate 405 the request by comparing the token value in request message with the 406 token in uniform authentication platform. If the match is successful, 407 MB will pre-subscribe the topics of user's message configuration 408 file. If failed, MB will reject the connection. 410 5.2.2 Connection Maintenance 412 MB maintains the connection with client(MUA) and replies to the MUA's 413 heartbeat request. If MB does not receive a message within a 414 reasonable amount of time from MUA, MB will mark the connection with 415 MUA is unreachable. 417 5.2.3 Sending Responses 419 When receiving a request message from MUA, MB will send a 420 corresponding response message back according to different message 421 types. And the response message has the same message ID with the 422 corresponding request message. The response message indicated that 423 the request massage has successfully received. 425 5.2.4 Processing Offline Messages 427 If the message receiver is offline, the message is stored on MB so 428 that it can be processed once the related receiver is back online. 430 5.2.5 Other Features 432 MB has some other features: 434 Topic Parsing: MB is responsible for parsing a new topic generated by 435 MUA and maintains the subscription policy to determine whether other 436 user is permitted to subscribe to the topic. For example, topic named 437 by the User ID is restricted to be subscribed only by user himself. 439 Permission Checking: MB performs ACL permission checkout and filters 440 the messages in relevant Topic of MUA. The filtering operation can be 441 set by system as well as its user. For example, if a Topic is set 442 "read", its user will only have the permission of receiving, if a 443 Topic is set "write", its user will only have the permission of 444 sending. 446 State Presenting: all the states are presented by user presence. 447 Presence is presenting the state of any terminal. State is related to 448 the type of terminal. When a user's presence state changes, MB will 449 inform all his friends. 451 MB to MB: it is the connection between two MBs and is considered as 452 the communicating extension between client and server. 454 6 Topic 456 6.1 Topic Policy 458 Topic can be considered as a class of instant message or control 459 message (which is used for the system management). And the MUA of 460 receiver needs to subscribe to the topic it is interested in. For 461 different types of topics, the subscription rules are different. The 462 first type is user-related topic which can be personally subscribed 463 to, i.e., topic belongs to a related user, and the user is the only 464 subscriber of the topic, and others are forbidden to subscribe to, 465 like one-to-one IM topic. Although the subscription of topic is 466 forbidden to other users, the publishing is permitted, and the other 467 users can publish IM to a user-related topic and MB forward the 468 message to the unique subscriber. The second type is conditional open 469 topic in which multiple subscriber is permitted under a certain 470 condition. For a group IM topic, only the creator of the group and 471 the users who have been invited could subscribe to the topic. 473 For different message types, the processes are different. This 474 document defines the service profile identifiers to distinguish 475 different message types. For example, the one-to-one messages' 476 service profile identifier is defined as '100' while the group 477 messages' is '200'. The one-to-one messages' topic is /100/User ID 478 while the group messages' is /200/Group ID. For one-to-one messages 479 service, MUA subscribes to the topic it is interested in, while for 480 group messages service, all the users in the group subscribe to a 481 same group topic. 483 6.2 Organization of Topic 485 The topic level separator is used to introduce structure into the 486 Topic Name. If present, it divides the Topic Name into multiple 487 "topic levels". The forward slash ('/' U+002F) is used to separate 488 each level within a topic tree and provide a hierarchical structure 489 to the Topic Names. 491 Some topics are defined according to the user behavior such as the 492 topic of adding friends is 'user/friend/new', deleting friends 493 corresponds to 'user/friend/delete', user's IM topic is user/chat 494 while the topic of state presenting is presence/user. Typically, the 495 users transmit instant messages with each other in user/chat. 497 Using adding friends as an example, when Alice wants to add Bob as 498 friend, she sends request message to BoB's topic, i.e., 499 Bob@example.com/friend/new. Then Bob sends response message to 500 Alice's topic, i.e., Alice@example.com/friend/new. If Bob accepts the 501 request, both of them should update their Message Configuration File. 503 6.3 Topic-based Message Routing 505 MB operates the function of message routing based on Topic. For a 506 large scale network, a multi-domain deployment plan is introduced. 507 Each domain can administer a certain number of users and the related 508 topics. Each topic name indicates the domain that the topic belongs 509 to. When MUA sends a message to the topic, the MB which the MUA 510 connected will parser the topic name and obtain the domain, and send 511 the message to the related domain. The MB which stores the topic will 512 receive the message and forward the message to subscriber(s). 514 7 Message Formats 516 7.1 Overview 518 Referring to MQTT protocol[OASIS Standard MQTT], this scheme defines 519 11 kinds of message types which are represented as a 4-bit unsigned 520 value. These messages types can be divided into 4 categories as 521 illustrated in Figure 7.1. 523 +--------------+------------+-------+-----------+----------------+ 524 | Category | Name | Value | Direction | Description | 525 | | | | of folw | | 526 +--------------+------------+-------+-----------+----------------+ 527 | | CONNECT | 1 | MUA -> MB | MUA request to | 528 | | | |or MB-> MUA| connect to MB | 529 | +------------+-------+-----------+----------------+ 530 | Connection | CONNACK | 2 | MB -> MUA | Connect | 531 | Class | | | | acknowledgment | 532 | +------------+-------+-----------+----------------+ 533 | | DISCONNECT | 3 | MUA -> MB | MUA is | 534 | | | | | disconnecting | 535 +--------------+------------+-------+-----------+----------------+ 536 | | PUBLISH | 4 | MUA -> MB | Publish message| 537 | Publication | | |or MB-> MUA| | 538 | Class +------------+-------+-----------+----------------+ 539 | | PUBACK | 5 | MUA -> MB | Publish | 540 | | | |or MB-> MUA| acknowledgment | 541 +--------------+------------+-------+-----------+----------------+ 542 | | SUBSCRIBE | 6 | MUA -> MB | MUA subscribe | 543 | | | | | request | 544 | +------------+-------+-----------+----------------+ 545 | | SUBACK | 7 | MB -> MUA | Subscribe | 546 | Subscription | | | | acknowledgment | 547 | Class +------------+-------+-----------+----------------+ 548 | | UNSUBSCRIBE| 8 | MUA -> MB | Unsubscribe | 549 | | | | | request | 550 | +------------+-------+-----------+----------------+ 551 | | UNSUBACK | 9 | MB -> MUA | Unsubscribe | 552 | | | | | acknowledgment | 553 +--------------+------------+-------+-----------+----------------+ 554 | Keep-alive | PINGREQ | 10 | MUA -> MB | PING request | 555 | Class +------------+-------+-----------+----------------+ 556 | | PINGRESP | 11 | MB -> MUA | PING response | 557 +--------------+------------+-------+-----------+----------------+ 559 Figure 7.1 - Message types 561 The message consists of up to three parts, always in the following 562 order as illustrated in Figure 7.2. 564 +-------------------------------+ 565 | Fixed header | 566 +-------------------------------+ 567 | Variable header | 568 +-------------------------------+ 569 | Payload | 570 +-------------------------------+ 572 Figure 7.2 - Message structure 574 7.1.1 Fixed Header 576 Each message contains a fixed header. Figure 7.3 illustrates the 577 fixed header format. 578 +-------+---+---+---+---+---+---+---+---+ 579 |Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 580 +-------+---+---+---+---+---+---+---+---+ 581 |byte 1 | Message Type | Flags | 582 +-------+---------------+---------------+ 583 |byte 2 | Remaining Length | 584 +-------+-------------------------------+ 586 Figure 7.3 - Fixed header format 588 Message Type: byte 1, bits 7-4. Represented as a 4-bit unsigned 589 value, different value expresses different message type. For example, 590 value 1 expresses the CONNECT message while value 2 expresses the 591 CONNACK message. 593 Flags: remaining bits 3-0 of byte 1, specific to each kind message. 595 Remaining Length: starts at byte 2, bits 7-0, the number of bytes 596 remaining within the current message, including data in the variable 597 header and the payload. The least significant seven bits of each byte 598 encode the data, and the most significant bit is used to indicate 599 that there are following bytes in the representation. The fixed 600 header can be extended to four bytes at most. 602 7.1.2 Variable Header 604 Some types of messages contain a variable header component. It 605 resides between the fixed header and the payload. The content of the 606 variable header varies depending on the message type. The Message 607 Identifier field of variable header is common in several message 608 types as illustrated in Figure 7.4. 610 +-------+---+---+---+---+---+---+---+ 611 |Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 612 +-------+---+---+---+---+---+---+---+ 613 |byte 1 | Message Identifier MSB | 614 +-------+---------------------------+ 615 |byte 2 | Message Identifier LSB | 616 +-------+---------------------------+ 618 Figure 7.4 - Message Identifier bytes 620 Message Identifier: two bytes, non-zero, unique identification of a 621 message. This specification defines 11 kinds of message types, 622 including CONNECT, CONNACK, PUBLISH, PUBACK, SUBSCRIBE, SUBACK, 623 UNSUBSCRIBE, UNSUBACK, PINGREQ, PINGRES and DISCONNECT. SUBSCRIBE, 624 UNSUBSCRIBE, and PUBLISH messages MUST contain a non-zero 16-bit 625 Message Identifier. Each time MUA sends a new message of one of these 626 types it MUST assign it a currently unused Message Identifier. If MUA 627 re-sends a message, then it MUST use the same Message Identifier in 628 subsequent re-sends of that message. The Message Identifier becomes 629 available for reuse after the MUA has processed the corresponding 630 acknowledgement message form MB. For PUBLISH it is the corresponding 631 PUBACK. For SUBSCRIBE or UNSUBSCRIBE it is the corresponding SUBACK 632 or UNSUBACK. 634 7.2 CONNECT 636 CONNECT, requesting connection, the fixed header as illustrated in 637 Figure 7.5. 639 +-------+---+---+---+----+---+---+---+---+ 640 |Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 641 +-------+---+---+---+----+---+---+---+---+ 642 |byte 1 |Message Type (1)| Reserved | 643 +-------+---+---+---+----+---+---+---+---+ 644 | | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 645 +-------+---+---+---+----+---+---+---+---+ 646 |byte 2 | Remaining Length | 647 +-------+--------------------------------+ 649 Figure 7.5 - CONNECT message fixed header 651 Message Type: 1, represent the CONNECT message; 653 Flags: 0, reserved for future use; 655 Remaining Length: uncertain, depend on the data in the variable 656 header and the payload. 658 The variable header carries the protocol version information as 659 illustrated in Figure 7.6. The protocol version is a UTF-8 encoded 660 string that represents the protocol version "IM0". 662 +-------+--------------+---+---+---+---+---+---+---+---+ 663 | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 664 +-------+--------------+---+---+---+---+---+---+---+---+ 665 |Protocol Version Information | 666 +-------+--------------+---+---+---+---+---+---+---+---+ 667 |byte 1 |Length MSB (0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 668 +-------+--------------+---+---+---+---+---+---+---+---+ 669 |byte 2 |Length LSB (4)| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 670 +-------+--------------+---+---+---+---+---+---+---+---+ 671 |byte 3 | 'I' | 0 | 1 | 0 | 0 | 1 | 0 | 0 | 1 | 672 +-------+--------------+---+---+---+---+---+---+---+---+ 673 |byte 4 | 'M' | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 674 +-------+--------------+---+---+---+---+---+---+---+---+ 675 |byte 5 | '0' | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 676 +-------+--------------+---+---+---+---+---+---+---+---+ 678 Figure 7.6 - CONNECT message variable header 680 As for the payload, it mainly includes personal information of user, 681 such as username and authentication Token and heart-beats 682 information. Username and authentication Token are the UTF-8 encoded 683 strings. 685 7.3 CONNACK 687 CONNACK is the MB's response of CONNECT, the fixed forehead as 688 illustrated in Figure 7.7. 690 +------+---+---+---+---+---+---+---+---+ 691 |Bit |7 |6 |5 |4 |3 |2 |1 |0 | 692 +------+---+---+---+---+---+---+---+---+ 693 |byte 1|Message Type(2)| Reserved | 694 +------+---+---+---+---+---+---+---+---+ 695 | |0 |0 |1 |0 |0 |0 |0 |0 | 696 +------+---+---+---+---+---+---+---+---+ 697 |byte 2|Remaining Length (2) | 698 +------+---+---+---+---+---+---+---+---+ 699 | |0 |0 |0 |0 |0 |0 |1 |0 | 700 +------+---+---+---+---+---+---+---+---+ 702 Figure 7.7 - CONNACK message fixed header 704 Message Type: 2, represent the CONNACK message; 705 Flags: 0, reserved for future use; 707 Remaining Length: 2, represent that there are 2 bytes remaining 708 within this message. 710 The variable header mainly contains 2 components: CONNECT Acknowledge 711 Flags and CONNECT Return code and its format is illustrated in Figure 712 7.8. 714 +--------+-----------------+---+---+---+---+---+---+---+---+ 715 | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 716 +--------+-----------------+---+---+---+---+---+---+---+---+ 717 |CONNECT Acknowledge Flags | Reserved |SP1| 718 +--------+-----------------+---+---+---+---+---+---+---+---+ 719 | byte 1 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | X | 720 +--------+-----------------+---+---+---+---+---+---+---+---+ 721 |CONNECT Return code | 722 +--------+-----------------+---+---+---+---+---+---+---+---+ 723 | byte 2 | | X | X | X | X | X | X | X | X | 724 +--------+-----------------+---+---+---+---+---+---+---+---+ 726 Figure 7.8 - CONNACK message variable header 728 CONNECT Acknowledge Flags: Bits 7-1 are reserved and MUST be set to 729 0. Bit 0 (SP1) is the Session Present Flag. 731 CONNECT Return code: represent the responding situation. 0 represents 732 that the connection is successful, 1 represents that the connection 733 is failed because of the unacceptable protocol version and 2 734 represents that connection is failed because of rejected user ID. 736 7.4 PUBLISH 738 PUBLISH, sent from MUA to MB or from MB to MUA to transport an 739 application message, the fixed header as illustrated in Figure 7.9. 740 Typically, 742 DUM = Duplicate delivery of a PUBLISH message; 744 RETAIN = PUBLISH retain flag. 746 +--------+-----+-----+-----+-----+--------+-----+-----+------+ 747 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 748 +--------+-----+-----+-----+-----+--------+-----+-----+------+ 749 | byte 1 | Message Type (4) |DUM flag| Reserved |RETAIN| 750 +--------+-----+-----+-----+-----+--------+-----+-----+------+ 751 | | 0 | 0 | 1 | 1 | X | X | X | X | 752 +--------+-----+-----+-----+-----+--------+-----+-----+------+ 753 | byte 2 | Remaining Length | 754 +--------+---------------------------------------------------+ 756 Figure 7.9 - PUBLISH message fixed header 758 Message Type: 4, represent the PUBLISH message; 760 DUM flag: 1 indicates that it is a retransmission message and 0 761 indicates it isn't. 763 RETAIN: 0 indicates that MB must not store the application message 764 and must not remove or replace any existing retained message, while 765 1indicates that the MB must store it. 767 Remaining Length: uncertain, depend on the data in the variable 768 header and the payload. 770 The variable header mainly contains 2 components: Topic Name and 771 Message Identifier. Figure 7.10 shows a non normative example 772 variable header, typically, the value of Topic Name set "a/b" and the 773 value of Message Identifier set 10 775 +--------+-----------------------------+---+---+---+---+---+---+---+---+ 776 | |Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 777 +--------+-----------------------------+---+---+---+---+---+---+---+---+ 778 | Topic Name | 779 +--------+-----------------------------+---+---+---+---+---+---+---+---+ 780 | byte 1 |Length MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 781 +--------+-----------------------------+---+---+---+---+---+---+---+---+ 782 | byte 2 |Length LSB (3) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 783 +--------+-----------------------------+---+---+---+---+---+---+---+---+ 784 | byte 3 | 'a' (0x61) | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 785 +--------+-----------------------------+---+---+---+---+---+---+---+---+ 786 | byte 4 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | 787 +--------+-----------------------------+---+---+---+---+---+---+---+---+ 788 | byte 5 | 'b' (0x62) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 789 +--------+-----------------------------+---+---+---+---+---+---+---+---+ 790 | Message Identifier | 791 +--------+-----------------------------+---+---+---+---+---+---+---+---+ 792 | byte 6 |Message Identifier MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 793 +--------+-----------------------------+---+---+---+---+---+---+---+---+ 794 | byte 7 |Message Identifier LSB (10) | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 795 +--------+-----------------------------+---+---+---+---+---+---+---+---+ 797 Figure 7.10 - PUBLISH message variable header non normative example 799 Topic Name: indicate which Topic is going to send data; 801 Payload in PUBLISH carries the data which is described in Topic, 802 i.e., the message content. 804 7.5 PUBACK PUBACK is the response of PUBLISH message and expresses that 805 the message is received successfully by MB. The fixed forehead is 806 illustrated in Figure 7.11. 808 +-------+---+---+---+---+---+---+---+---+ 809 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 810 +-------+---+---+---+---+---+---+---+---+ 811 | byte 1|Message Type(5)| Reserved | 812 +-------+---+---+---+---+---+---+---+---+ 813 | | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 814 +-------+---+---+---+---+---+---+---+---+ 815 | byte 2| Remaining Length (2) | 816 +-------+---+---+---+---+---+---+---+---+ 817 | | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 818 +-------+---+---+---+---+---+---+---+---+ 820 Figure 7.11 - PUBACK message fixed header 822 Except the Message Type, the description of message field is the same 823 as CONNACK. The value of Message Type is 5. 825 The variable header of PUBACK is a message descriptor as same as 826 PUBLISH: 828 +---------+---+---+---+---+---+---+---+---+ 829 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 830 +---------+---+---+---+---+---+---+---+---+ 831 | byte 1 | Message Identifier MSB | 832 +---------+-------------------------------+ 833 | byte 2 | Message Identifier LSB | 834 +---------+-------------------------------+ 836 Figure 7.12 - PUBACK message variable header 838 7.6 SUBSCRIBE 840 SUBSCRIBE expresses the subscription of Topic and the specification 841 allows to define more than one Topic in a SUBSCRIBE. The fixed 842 forehead is illustrated in Figure 7.13. 844 +-------+---+---+---+---+---+---+---+---+ 845 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 846 +-------+---+---+---+---+---+---+---+---+ 847 | byte 1|Message Type(6)| Reserved | 848 +-------+---+---+---+---+---+---+---+---+ 849 | | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 850 +-------+---+---+---+---+---+---+---+---+ 851 | byte 2| Remaining Length | 852 +---------------------------------------+ 854 Figure 7.13 - SUBSCRIBE message fixed header 856 Message Type: 6, represent the SUBSCRIBE message; 858 Flags: 2, reserved for future use. Attention, it must be set to 2 859 respectively. The MB must treat any other value as malformed and 860 close the network connection; 862 Remaining Length: uncertain, depend on the data in the variable 863 header and the payload. The variable header contains a Message 864 Identifier. Figure 7.14 shows a variable header with Message 865 Identifier set to 10. 867 +------+---------------------------+---+---+---+---+---+---+---+---+ 868 | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 869 +------+---------------------------+---+---+---+---+---+---+---+---+ 870 |Message Identifier | 871 +------+---------------------------+---+---+---+---+---+---+---+---+ 872 |byte 1|Message Identifier MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 873 +------+---------------------------+---+---+---+---+---+---+---+---+ 874 |byte 2|Message Identifier LSB (10)| 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 875 +------+---------------------------+---+---+---+---+---+---+---+---+ 877 Figure 7.14 - SUBSCRIBE message variable header 879 The payload of a SUBSCRIBE message contains a list of Topic Filters 880 indicating the Topics to which the MUA wants to subscribe. The Topic 881 Filters in a SUBSCRIBE message payload MUST be UTF-8 encoded strings. 882 The payload is illustrated in Figure 7.15. 884 +-----------+---+---+---+---+---+---+---+---+ 885 |Description| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 886 +-----------+---+---+---+---+---+---+---+---+ 887 |Topic Filter | 888 +-----------+-------------------------------+ 889 |byte 1 |Length MSB | 890 +-----------+-------------------------------+ 891 |byte 2 |Length LSB | 892 +-----------+-------------------------------+ 893 |bytes 3..N |Topic Filter | 894 +-----------+-------------------------------+ 896 Figure 7.15 - SUBSCRIBE message payload 898 7.7 SUBACK 900 SUBACK is MB's response of SUBSCRIBE. The fixed forehead is 901 illustrated in Figure 7.16. 903 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 904 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 905 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 906 | byte 1| MQTT Message Type (7) | Reserved | 907 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 908 | | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 909 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 910 | byte 2| Remaining Length | 911 +-------------------------------------------------------+ 913 Figure 7.16 - SUBSCRIBE message fixed header 915 Except the Message Type, the description of message field is the same 916 as PUBACK. The value of Message Type is 7. 918 The variable header contains the Message Identifier from the 919 SUBSCRIBE message that is being acknowledged. Figure 7.17 illustrates 920 the format of the variable header. 922 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 923 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 924 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 925 | byte 1| Message Identifier MSB | 926 +-------+-----------------------------------------------+ 927 | byte 2| Message Identifier LSB | 928 +-------+-----------------------------------------------+ 930 Figure 7.17 - SUBSCRIBE message variable header 932 The payload contains a list of return codes. Each return code 933 corresponds to a Topic Filter in the SUBSCRIBE message being 934 acknowledged. The order of return codes in the SUBACK message must 935 match the order of Topic Filters in the SUBSCRIBE message. Figure 936 7.18 illustrates the format of the variable header. 938 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 939 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 940 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 941 | | Return Code | 942 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 943 | byte 1| X | 0 | 0 | 0 | 0 | 0 | X | X | 944 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 946 Figure 7.18 - SUBSCRIBE message payload 948 Allowed return codes: 950 0x00 - Success; 952 0x80 - Failure. 954 7.8 UNSUBSCRIBE 956 UNSUBSCRIBE expresses canceling the subscription of a Topic and the 957 specification allows canceling subscription of different Topics at a 958 time. The fixed forehead is illustrated in Figure 7.19. 960 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 961 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 962 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 963 | byte 1| Message Type (8) | Reserved | 964 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 965 | | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | 966 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 967 | byte 2| Remaining Length | 968 +-------+-----------------------------------------------+ 970 Figure 7.19 - UNSUBSCRIBE message fixed header 972 Except the Message Type, the description of message field is the same 973 as he UNSUBSRIBE. The value of Message Type is 8. 975 The variable header is the message descriptor, as illustrated in 976 Figure 7.20. 978 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 979 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 980 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 981 | byte 1| Message Identifier MSB | 982 +-------+-----------------------------------------------+ 983 | byte 2| Message Identifier LSB | 984 +-------+-----------------------------------------------+ 986 Figure 7.20 - UNSUBSCRIBE message variable header 988 The payload for the UNSUBSCRIBE message contains the list of Topic 989 Filters that the MUA wishes to unsubscribe from. The Topic Filters in 990 an UNSUBSCRIBE message must be UTF-8 encoded strings. Figure 7.21 991 shows a non normative example payload, typically, it set two Topic 992 Filters, the one is "a/b" and the other one is "c/d". 994 +------------+--------------+---+---+---+---+---+---+---+---+ 995 | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 996 +------------+--------------+---+---+---+---+---+---+---+---+ 997 |Topic Filter | 998 +------------+--------------+---+---+---+---+---+---+---+---+ 999 | byte 1 |Length MSB (0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1000 +------------+--------------+---+---+---+---+---+---+---+---+ 1001 | byte 2 |Length LSB (3)| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1002 +------------+--------------+---+---+---+---+---+---+---+---+ 1003 | byte 3 | 'a' (0x61) | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1004 +------------+--------------+---+---+---+---+---+---+---+---+ 1005 | byte 4 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | 1006 +------------+--------------+---+---+---+---+---+---+---+---+ 1007 | byte 5 | 'b' (0x62) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 1008 +------------+--------------+---+---+---+---+---+---+---+---+ 1009 |Topic Filter | 1010 +------------+--------------+---+---+---+---+---+---+---+---+ 1011 | byte 6 |Length MSB (0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1012 +------------+--------------+---+---+---+---+---+---+---+---+ 1013 | byte 7 |Length LSB (3)| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1014 +------------+--------------+---+---+---+---+---+---+---+---+ 1015 | byte 8 | 'c' (0x63) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 1016 +------------+--------------+---+---+---+---+---+---+---+---+ 1017 | byte 9 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | 1018 +------------+--------------+---+---+---+---+---+---+---+---+ 1019 | byte 10 | 'd' (0x64) | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 1020 +------------+--------------+---+---+---+---+---+---+---+---+ 1022 Figure 7.21 - UNSUBSCRIBE message payload non normative example 1024 7.9 UNSUBACK 1026 UNSUBACK is MB's response of UNSUBSCRIBE. The fixed forehead is 1027 illustrated in Figure 7.22. 1029 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1030 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 1031 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1032 | byte 1| Message Type (9) | Reserved | 1033 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1034 | | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1035 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1036 | byte 2| Remaining Length (2) | 1037 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1038 | | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1039 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1041 Figure 7.22 - UNSUBSACK message fixed header 1043 The value of Message Type is 9. 1045 The variable header is the message descriptor, as illustrated in 1046 Figure 7.23. 1048 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1049 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 1050 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1051 | byte 1| Message Identifier MSB | 1052 +-------------------------------------------------------+ 1053 | byte 2| Message Identifier LSB | 1054 +-------------------------------------------------------+ 1056 Figure 7.23 - UNSUBACK message variable header. 1058 7.10 PINGREQ 1060 Heartbeat message, which the MUA sent to MB, only has fixed forehead. 1061 The fixed forehead is illustrated in Figure 7.24. 1063 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1064 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 1065 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1066 | byte 1| Message Type (10) | Reserved | 1067 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1068 | | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 1069 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1070 | byte 2| Remaining Length (0) | 1071 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1072 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1073 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1075 Figure 7.24 - PINGREQ message fixed header 1077 Message Type: 10, represent the PINGREQ message; 1079 Flags: 0, reserved for future use; 1081 Remaining Length: 0, no variable header or the payload. 1083 7.11 PINGRSEP 1085 The response of PINGREQ message, only has fixed forehead which is 1086 illustrated in Figure 7.25. 1088 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1089 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 1090 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1091 | byte 1| Message Type (11) | Reserved | 1092 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1093 | | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1094 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1095 | byte 2| Remaining Length (0) | 1096 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1097 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1098 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1100 Figure 7.25 - PINGRSEP message fixed header 1102 Except the Message Type, the description of message field is the same 1103 as PINGREQ. The value of Message Type is 11. 1105 7.12 DISCONNECT 1107 The DISCONNECT message indicates that the MUA is disconnecting 1108 cleanly. It has fixed forehead only as illustrated in Figure 7.26 1109 with no variable header or payload. 1111 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1112 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 1113 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1114 | byte 1| Message Type (3) | Reserved | 1115 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1116 | | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1117 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1118 | byte 2| Remaining Length (0) | 1119 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1120 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1121 +-------+-----+-----+-----+-----+-----+-----+-----+-----+ 1123 Figure 7.26 - DISCONNECT message fixed header 1125 8 Compatibility Considerations 1126 This document extends a SIP method, IMX, where 'IM' means Instant 1127 Message and 'X' is the version number of the protocol. IMX is used 1128 for the registration of the SIP device which integrated with UA and 1129 MUA. The following is an example of the SIP REGISTER message where 1130 the IP of SIP server is 192.168.2.89 and the IP of SIP device is 1131 192.168.2.161. 1133 REGISTER sip:192.168.2.89 SIP/2.0 1134 Via: SIP/2.0/UDP 192.168.2.161:10586 1135 Max-Forwards: 70 1136 From: ;tag=ca04c1391af3429491f2c4dfb 1137 e5e1b2e;epid=4f2e395931 1138 To: 1139 Call-ID: da56b0fab5c54398b16c0d9f9c0ffcf2@192.168.2.161 1140 CSeq: 1 REGISTER 1141 Contact: ;methods="INVITE, IM0, MESSAGE, 1142 INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER" 1143 User-Agent: RTC/1.2.4949 (BOL SIP Phone 1005) 1144 Event: registration 1145 Allow-Events: presence 1146 Content-Length: 0 1148 Optionally, the response of SIP REGISTER message could carry a 1149 security token and the token is used for authenticating MUA of MB. 1150 MUA sends token to MB, MB validates the correctness of the token and 1151 thus complete the registration process of MUA. The following is an 1152 example of the response of SIP REGISTER message and the token can be 1153 encrypted, optionally. 1155 SIP/2.0 200 OK 1156 Via: SIP/2.0/UDP 192.168.2.161:10586 1157 From: ;tag=ca04c1391af3429491f2c4dfb 1158 e5e1b2e;epid=4f2e395931 1159 To: ;tag=-00834-14d0805b62bc026d 1160 Call-ID: da56b0fab5c54398b16c0d9f9c0ffcf2@192.168.2.161 1161 CSeq: 1 REGISTER 1162 Allow: INVITE, IMX, ACK, OPTIONS, BYE, CANCEL, REGISTER, INFO, 1163 UPDATE, PRACK, REFER, SUBSCRIBE, NOTIFY, MESSAGE 1164 Contact: sip:192.168.2.161:10586 1165 Content-Type: text/plain 1166 Content-Length: 32 1167 Expires: 3600 1169 6629fae49393a05397450978507c4ef1 1171 The proposed scheme follows the extension of SIP protocol. Entity MUA 1172 provides backwards compatibility with SIP UA. The definition of MUA 1173 and MB meets the extension demand of SIP entity, furthermore, MUA and 1174 MB can interact with SIP logical entity normally. For example, when 1175 MUA requests authentication and registration, it sends registration 1176 message to application server firstly, and then application server 1177 would assign the most suitable MB for MUA and notify MUA if the 1178 message is matched. The message used in this process is in accordance 1179 with the method in SIP, which maintains compatibility about messages. 1181 And as a specific condition where the IP of SIP UA has changed, if 1182 connection between MUA and MB exists, UA does not need to register to 1183 SIP server. When a call arrives at the SIP server, server will send 1184 calling instant message to MUA via MB and MUA parsers the message and 1185 wake up UA, then UA will register to server and process the call. 1187 9 Security Considerations 1189 Although the message publisher and receiver are loosely-coupled while 1190 transmitting messages, the security can be ensured. Firstly, before 1191 subscribing or publishing, MUAs need to authenticate and register 1192 user authentication information with AS. In the process, the username 1193 and password must be encrypted to prevent interception of assertions. 1194 Secondly, the username and password stored in AS are also encrypted 1195 to prevent identity leakage. Thirdly, MB only sends messages of a 1196 Topic to the MUA which has been authenticated and subscribed the 1197 related Topic. The authentication and topic management belong to 1198 different entities, and it could avoid network attacks and was under 1199 firm security. When the IP address changes, current transmitting will 1200 stop and MUAs need to send a CONNECT message to MB to create a new 1201 connection. The message content should be encrypted by the encryption 1202 algorithm to ensure integrality and reliability of the message. 1204 10 References 1205 10.1 Normative Reference 1207 [IETF SIMPLE WG] 1208 International Business Machines Corporation (IBM), "MQTT 1209 Version 3.1.1", OASIS Standard, October 2014, 1210 http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt- 1211 v3.1.1-os.html. 1213 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1214 A., Peterson, J., Sparks, R., Handley, M., and E. 1215 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1216 DOI 10.17487/RFC3261, June 2002, . 1219 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1220 "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 1221 10.17487/RFC4975, September 2007, . 1224 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1225 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1226 DOI 10.17487/RFC4976, September 2007, . 1229 [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., 1230 Huitema, C., and D. Gurle, "Session Initiation Protocol 1231 (SIP) Extension for Instant Messaging", RFC 3428, DOI 1232 10.17487/RFC3428, December 2002, . 1235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1236 Requirement Levels", BCP 14, RFC 2119, DOI 1237 10.17487/RFC2119, March 1997, . 1240 10.2 Informative References 1241 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1242 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1243 March 2011, . 1245 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1246 Protocol (XMPP): Instant Messaging and Presence", 1247 RFC 6121, DOI 10.17487/RFC6121, March 2011, 1248 . 1250 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1251 (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, 1252 . 1254 [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and 1255 Presence Protocol (XMPP) to Common Presence and Instant 1256 Messaging (CPIM)", RFC 3922, DOI 10.17487/RFC3922, October 1257 2004, . 1259 [OASIS Standard MQTT] 1260 International Business Machines Corporation (IBM), "MQTT 1261 Version 3.1.1", OASIS Standard, October 2014, 1262 http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt- 1263 v3.1.1-os.html. 1265 Authors' Addresses 1267 Jianping Zheng 1268 China Mobile Communications Corporation 1269 China Mobile Research Institute 1270 Beijing, 100031 1271 P. R. China 1273 Email: zhengjianping@chinamobile.com 1275 Yichuan Wu 1276 China Mobile Communications Corporation 1277 China Mobile Research Institute 1278 Beijing, 100031 1279 P. R. China 1281 Email: wuyichuan@chinamobile.com 1283 Weimin Lei 1284 Northeastern University 1285 School of Computer Science and Engineering 1286 Shenyang, China, 110819 1287 P. R. China 1289 Email: leiweimin@mail.neu.edu.cn 1291 Wei Zhang 1292 Northeastern University 1293 School of Computer Science and Engineering 1294 Shenyang, China, 110819 1295 P. R. China 1297 Email: zhangwei1@mail.neu.edu.cn 1299 Hao Li 1300 Northeastern University 1301 School of Computer Science and Engineering 1302 Shenyang, China, 110819 1303 P. R. China 1305 Email: haoli2015@stumail.neu.edu.cn