├── CHANGELOG.md
├── LICENSE
├── README.md
└── docs
    └── index.md


/CHANGELOG.md:
--------------------------------------------------------------------------------
 1 | # Protocol Spec 5.1.0
 2 | 
 3 | ## Implemented Proposals
 4 | 
 5 | 
 6 | - [[SDL 0162] Define Handling of Duplicate Correlation IDs](https://github.com/smartdevicelink/protocol_spec/issues/17)
 7 | 
 8 | - [[SDL 0141] Supporting simultaneous multiple transports](https://github.com/smartdevicelink/protocol_spec/issues/15)
 9 | 
10 | 


--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
 1 | Copyright (c) 2015, 
 2 | All rights reserved.
 3 | 
 4 | Redistribution and use in source and binary forms, with or without
 5 | modification, are permitted provided that the following conditions are met:
 6 | 
 7 | * Redistributions of source code must retain the above copyright notice, this
 8 |   list of conditions and the following disclaimer.
 9 | 
10 | * Redistributions in binary form must reproduce the above copyright notice,
11 |   this list of conditions and the following disclaimer in the documentation
12 |   and/or other materials provided with the distribution.
13 | 
14 | * Neither the name of protocol_spec nor the names of its
15 |   contributors may be used to endorse or promote products derived from
16 |   this software without specific prior written permission.
17 | 
18 | THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
19 | AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
20 | IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
21 | DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
22 | FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
23 | DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
24 | SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
25 | CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
26 | OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
27 | OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
28 | 
29 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
   1 | # SmartDeviceLink Protocol
   2 | 
   3 | **Current Version: 5.4.1**
   4 | 
   5 | ## 1. Overview
   6 | The SmartDeviceLink protocol specification describes the method for establishing communication between an application and head unit and registering the application for continued communication with the head unit. The protocol is used as the base formation of packets sent from one module to another. 
   7 | 
   8 | All new SDL implementations should implement the newest version of the protocol.
   9 | 
  10 | ### 1.1 Common Terms
  11 | 
  12 | | Term | Description |
  13 | |------|-------------|
  14 | |**Module / Head Unit**| Hardware implementing the sdl_core software|
  15 | |**Application**| Smart device application that implements the proxy library (iOS or Android)|
  16 | 
  17 | ## 2. Frames
  18 | All transported data is formed with a header followed by an optional payload. The combination of header and payload is referred to as a frame.
  19 | 
  20 | ### 2.1 Version 1 Frame Header
  21 | >Deprecated: Protocol versions 2 and higher. Only used as initial `StartService` packet for establishing communication and version negotiation from application
  22 | 
  23 | 
  24 | <table>
  25 |   <tr>
  26 |     <th colspan="3" width="25%">Byte 1</th>
  27 |     <th width="25%">Byte 2</th>
  28 |     <th width="25%">Byte 3</th>
  29 |     <th width="25%">Byte 4</th>
  30 |   </tr>
  31 |   <tr align="center">
  32 |     <td width="12.5%">Version</td>
  33 |     <td width="3.125%">C</td>
  34 |     <td width="9.375%">Frame Type</td>
  35 |     <td>Service Type</td>
  36 |     <td>Frame Info</td>
  37 |     <td>Session ID</td>
  38 |   </tr>
  39 | </table>
  40 | 
  41 | <table>
  42 |   <tr>
  43 |     <th width="250">Byte 5</th>
  44 |     <th width="25%">Byte 6</th>
  45 |     <th width="25%">Byte 7</th>
  46 |     <th width="25%">Byte 8</th>
  47 |   </tr>
  48 |   <tr>
  49 |     <td colspan="4" align="center">Data Size</td>
  50 |   </tr>
  51 | </table>
  52 | 
  53 | ### 2.2 Version 2 Frame Header
  54 | >Required: Protocol versions 2 and higher
  55 | 
  56 | <table>
  57 |   <tr>
  58 |     <th colspan="3" width="25%">Byte 1</th>
  59 |     <th colspan="1"width="25%">Byte 2</th>
  60 |     <th width="25%">Byte 3</th>
  61 |     <th width="25%">Byte 4</th>
  62 |   </tr>
  63 |   <tr align="center">
  64 |     <td width="12.5%">Version</td>
  65 |     <td width="3.125%">E</td>
  66 |     <td width="9.375%">Frame Type</td>
  67 |     <td>Service Type</td>
  68 |     <td>Frame Info</td>
  69 |     <td>Session ID</td>
  70 |   </tr>
  71 | </table>
  72 | 
  73 | <table >
  74 |   <tr>
  75 |     <th width="300">Byte 5</th>
  76 |     <th width="25%">Byte 6</th>
  77 |     <th width="25%">Byte 7</th>
  78 |     <th width="25%">Byte 8</th>
  79 |   </tr>
  80 |   <tr>
  81 |     <td colspan="4" align="center">Data Size</td>
  82 |   </tr>
  83 | </table>
  84 | 
  85 | <table>
  86 |   <tr>
  87 |     <th width="300">Byte 9</th>
  88 |     <th width="25%">Byte 10</th>
  89 |     <th width="25%">Byte 11</th>
  90 |     <th width="25%">Byte 12</th>
  91 |   </tr>
  92 |   <tr>
  93 |     <td colspan="4" align="center">Message ID</td>
  94 |   </tr>
  95 | </table>
  96 | 
  97 | ### 2.3 Frame Header Fields
  98 | 
  99 | <table width="100%">
 100 |   <tr>
 101 |     <th>Field</th>
 102 |     <th>Size</th>
 103 |     <th width="75%">Description</th>
 104 |   </tr>
 105 |   <tr>
 106 |     <td>Version</td>
 107 |     <td>4 bit</td>
 108 |     <td>
 109 |       <b>Protocol Version</b><br>
 110 |       0x1 Protocol version 1 - uses a version 1 Frame Header<br>
 111 |       0x2 Protocol version 2 - uses a version 2 Frame Header<br>
 112 |       0x3 Protocol version 3 - uses a version 2 Frame Header<br>
 113 |       0x4 Protocol version 4 - uses a version 2 Frame Header<br>
 114 |       0x5 Protocol version 5 - uses a version 2 Frame Header<br>
 115 |       0x6 - 0xF Reserved
 116 |     </td>
 117 |   </tr>
 118 |   <tr>
 119 |     <td>C</td>
 120 |     <td>1 bit</td>
 121 |     <td><b>Compression Flag</b> <br> 0x0 This packet is not compressed <br> 0x1 This packet is compressed <br> <b>Note:</b> Only available in Protocol Version 1</td>
 122 |   </tr>
 123 |   <tr>
 124 |     <td>E</td>
 125 |     <td>1 bit</td>
 126 |     <td><b>Encryption Flag</b> <br> 0x0 This packet is not encrypted <br> 0x1 This packet is encrypted <br> <b>Note:</b> Only available in Protocol Version 2 and higher. Must be always set to zero for a First Frame</td>
 127 |   </tr>
 128 |   <tr>
 129 |     <td>Frame Type</td>
 130 |     <td>3 bit</td>
 131 |     <td>
 132 |       0x00 Control Frame <br>
 133 |       0x01 Single Frame <br>
 134 |       0x02 First Frame <br>
 135 |       0x03 Consecutive Frame <br>
 136 |       0x04 - 0x07 Reserved
 137 |     </td>
 138 |   </tr>
 139 |   <tr>
 140 |     <td>Service Type</td>
 141 |     <td>8 bit</td>
 142 |     <td>
 143 |       0x00 Control Service<br>
 144 |       0x01 - 0x06 Reserved<br>
 145 |       0x07 Remote Procedure Call (RPC) Service<br>
 146 |       0x08 - 0x09 Reserved<br>
 147 |       0x0A Audio Service<br>
 148 |       0x0B Video Service<br>
 149 |       0x0C - 0x0E Reserved<br>
 150 |       0x0F Bulk Data (Hybrid Service)<br>
 151 |       0x10 - 0xFF Reserved
 152 |     </td>
 153 |   </tr>
 154 |   <tr>
 155 |     <td>Frame Info</td>
 156 |     <td>8 bit</td>
 157 |     <td>
 158 |       <b>Frame Type = 0x00 (Control Frame)</b><br>
 159 |       0x00 Heartbeat<br>
 160 |       0x01 Start Service<br>
 161 |       0x02 Start Service ACK<br>
 162 |       0x03 Start Service NAK<br>
 163 |       0x04 End Service<br>
 164 |       0x05 End Service ACK<br>
 165 |       0x06 End Service NAK<br>
 166 |       0x07 Register Secondary Transport<br>
 167 |       0x08 Register Secondary Transport ACK<br>
 168 |       0x09 Register Secondary Transport NAK<br>
 169 |       0x0A - 0xFC Reserved<br>
 170 |       0xFD Transport Event Update<br>
 171 |       0xFE Service Data ACK<br>
 172 |       0xFF Heartbeat ACK<br>
 173 |       <b>Frame Type = 0x01 (Single Frame)</b><br>
 174 |       0x00 - 0xFF Reserved<br>
 175 |       <b>Frame Type = 0x02 (First Frame)</b><br>
 176 |       0x00 - 0xFF Reserved<br>
 177 |       <b>Frame Type = 0x03 (Consecutive Frame)</b><br>
 178 |       0x00 Last Frame<br>
 179 |       0x01 - 0xFF Frame Number
 180 |     </td>
 181 |   </tr>
 182 |   <tr>
 183 |     <td>Session ID</td>
 184 |     <td>8 bit</td>
 185 |     <td>The session identifier</td>
 186 |   </tr>
 187 |   <tr>
 188 |     <td>Data Size</td>
 189 |     <td>32 bit</td>
 190 |     <td>
 191 |       <b>Frame Type = 0x00 (Control Frame)</b><br>
 192 |       0x0 - 0xFFFFFFFF reserved.<br>
 193 |       <b>Frame Type = 0x02 (First Frame)</b><br>
 194 |       0x08 The data size for a first frame is always 8 bytes. In the payload, the first four bytes denote the Total Size of the data contained in all consecutive frames. This is always the size of whole non-encrypted payload (even if consecutive frames are encrypted). The second four bytes denote the number of consecutive frames following this one<br>
 195 |       <b>Frame Type = 0x01 or 0x03 (Single or Consecutive Frame)</b><br>
 196 |       The total bytes in this frame's payload. If frame is encrypted this is the size of encrypted payload, otherwise size of non-encrypted payload.
 197 |     </td>
 198 |   </tr>
 199 |   <tr>
 200 |     <td>Message ID</td>
 201 |     <td>32 bit</td>
 202 |     <td>The message identifier, used to uniquely identify this message.<br> 
 203 |     <b>Note:</b> Only included in protocol version 2 frame headers and higher</td>
 204 |   </tr>
 205 | </table>
 206 | 
 207 | ### 2.4 Max Transport Units
 208 | The max transport unit (MTU) of a frame varies based on version. The MTU includes the frame header and payload. The current supported versions and their MTU's respectively are described below.
 209 | 
 210 | | Version | MTU (bytes) |
 211 | |------|-------------|
 212 | |**1**| 1500|
 213 | |**2**| 1500|
 214 | |**3**| 131,084 |
 215 | |**4**| 131,084|
 216 | |**5**| 131,084 default or negotiated *(See Control Frame Payloads)*
 217 | 
 218 | 
 219 | #### 2.4.1 Payload Size
 220 | The payload size is determined by the MTU - Frame Header Size. 
 221 | 
 222 | | Version | Max Payload Size (bytes) |
 223 | |------|-------------|
 224 | |**1**| 1488|
 225 | |**2**| 1488|
 226 | |**3**| 131,072 |
 227 | |**4**| 131,072|
 228 | |**5**| 131,072 default or (Negotiated MTU - 12 bytes) *(See Control Frame Payloads)*
 229 | 
 230 | #### 2.4.2 Encrypted MTU
 231 | While the supported MTU is the maximum size for that version, if a frame is encrypted it will be subject to the MTU of that encryption protocol as well. That means the MTU will have to be the minimum between SDL's MTU  and the encryption protocol's MTU. 
 232 | 
 233 | ## 3. Frame Types
 234 | 
 235 | ### 3.1 Control Frame 
 236 | Control frames are the lowest-level type of packets. They can be sent over any of the defined services. They are used for the control of the services in which they are sent.
 237 | 
 238 | #### 3.1.1 Special Header Definitions:
 239 | | Header Value |Expected values| Description |
 240 | |--------------|---------------|-------------|
 241 | |Frame Info| `0x00` - `0x06`, `0xFE`, `0xFF`|See below "Frame Info Definitions"|
 242 | |Data Size| `0x00`, `0x04`|`0x00` - Majority of control packets do not have payloads<br><br> `0x04` - Used for `StartServiceACK` where the payload is a HashID |
 243 | 
 244 | 
 245 | #### 3.1.2 Frame Info Definitions:
 246 | | Frame Info Value| Name | Description |
 247 | |------------|------|-------------|
 248 | | 0x00| Heartbeat| A ping packet that is sent to ensure the connection is still active and the service is still valid|
 249 | | 0x01 | Start Service |Requests that a specific type of service is started |
 250 | | 0x02 | Start Service ACK | Acknowledges that the specific service has been started successfully
 251 | | 0x03 | Start Service NAK | Negatively acknowledges that the specific service was *not* started
 252 | | 0x04 | End Service | Requests that a specific type of service is ended
 253 | | 0x05 | End Service ACK | Acknowledges that the specific service has been ended successfully
 254 | | 0x06 | End Service NAK |  Negatively acknowledges that the specific service was *not* ended or has not yet been started
 255 | | 0x07 | Register Secondary Transport | Request for a session registered on a primary transport to use a secondary transport. <br>This frame should only be sent on the Secondary Transport that the session is requesting.
 256 | | 0x08 | Register Secondary Transport ACK | Acknowledges that the supplied session is registered to use the requested Secondary Transport. The application is only allowed to send additional frames on the Secondary Transport after this frame is received. <br>This frame must be sent on the Secondary Transport in which the original request was sent. 
 257 | | 0x09 | Register Secondary Transport NAK | Negatively acknowledges that the session is not registered or able to use the current Secondary Transport. The application cannot use this transport for any other messages. <br>This frame must be sent on the Secondary Transport in which the original request was sent. 
 258 | | 0xFD | Transport Event Update | Indicates that status or configuration of one or more transports are updated. This frame must only be sent after the successful starting of the RPC service which includes the protocol version negotiation.
 259 | | 0xFE | Service Data ACK | *Deprecated*
 260 | | 0xFF | Heartbeat ACK | Acknowledges that a Heartbeat control packet has been received
 261 | 
 262 | #### 3.1.3 Payloads
 263 | >Added: Protocol Version 5<br>
 264 | >*Note: All parameters are optional*<br>
 265 | 
 266 | Control frames use [BSON](http://bsonspec.org) to store payload data. All payload types are directly from the BSON spec. Each control frame info type will have a defined set of available data. Most types will also have differently available data based on their service type.
 267 | 
 268 | If there is no data to send for a given parameter, the parameter should not be included. 
 269 | 
 270 | **Note:** Heartbeat, Heartbeat ACK, and Service Data ACK control frame types are not covered for any service as they were deprecated before payloads were introduced.
 271 | 
 272 | ##### 3.1.3.1 Control Service
 273 | 
 274 | ###### 3.1.3.1.1 Register Secondary Transport
 275 | 
 276 | >No parameters
 277 | 
 278 | ###### 3.1.3.1.2 Register Secondary Transport ACK
 279 | 
 280 | >No parameters
 281 | 
 282 | ###### 3.1.3.1.3 Register Secondary Transport NAK
 283 | 
 284 | | Tag Name | Type | Introduced | Description |
 285 | |----------|------|------------|-------------|
 286 | | reason | String | 5.1.0 | A string describing the reason of failure |
 287 | 
 288 | ###### 3.1.3.1.4 Transport Event Update
 289 | 
 290 | | Tag Name | Type | Introduced | Description |
 291 | |----------|------|------------|-------------|
 292 | | tcpIpAddress | String | 5.1.0 | IP address that can be used to establish a TCP connection. It can be IPv4 address (example: "192.168.1.1") or IPv6 address (example: "fd12:3456:789a::1").<br>An empty string indicates that the TCP transport becomes unavailable. |
 293 | | tcpPort | int32 | 5.1.0 |  TCP Port number that can be used along with the supplied `tcpIpAddress` to establish a TCP connection. If parameter is included, the `tcpIpAddress` parameter must also be included.|
 294 | 
 295 | ##### 3.1.3.2 RPC Service
 296 | 
 297 | ###### 3.1.3.2.1 Start Service
 298 | **Note:** While this includes a payload, it will remain a v1 frame header to ensure backwards compatibility with older systems.
 299 | 
 300 | | Tag Name | Type | Introduced | Description |
 301 | |----------|------|------------|-------------|
 302 | |protocolVersion|String| 5.0.0 | The max version of the protocol supported by client requesting service to start. Must be in the format *"Major.Minor.Patch"*|
 303 | 
 304 | ###### 3.1.3.2.2 Start Service ACK
 305 | | Tag Name | Type | Introduced | Description |
 306 | |----------|------|------------|-------------|
 307 | |protocolVersion|String| 5.0.0 |The negotiated version of the protocol. Must be in the format *"Major.Minor.Patch"*. The frame header version should match the major version exactly.|
 308 | |hashId|int32| 5.0.0 | Hash ID to identify this session and used when sending an `EndService` control frame for the RPC service type|
 309 | |mtu| int64 | 5.0.0 | Max transport unit to be used for this service|. If not included the client should use the protocol version default.|
 310 | |secondaryTransports|String Array| 5.1.0 | Array of transport types which are allowed to be used as a Secondary Transport. Refer to the table below for possible values.<br>As of this protocol spec version (5.1.0) only a single Secondary Transport may be used beyond a primary transport for a given session.<br>If there are no currently available Secondary Transports or the functionality is not supported, this parameter should be omitted or be an empty array.|
 311 | |audioServiceTransports|int32 array| 5.1.0 | Ordered list of transport priority types that support the audio service (`0x0A`). Only the values of `1` ("Primary Transport") or `2` ("Secondary Transport") shall be used. If both the primary and secondary transport support the audio service, both should be included (`1` and `2`) in the order they are preferred; otherwise only the single transport priority type should be included. An application must not start the audio service on a transport priority type that is not listed in the array.<br>If this parameter is not included the Primary Transport should be used for the audio service.|
 312 | |videoServiceTransports|int32 array| 5.1.0 | Ordered list of transport priority types that support the video service (`0x0B`). Only the values of `1` ("Primary Transport") or `2` ("Secondary Transport") shall be used. If both the primary and secondary transport support the video service, both should be included (`1` and `2`) in the order they are preferred; otherwise only the single transport priority type should be included. An application must not start the video service on a transport priority type that is not listed in the array.<br>If this parameter is not included the Primary Transport should be used for the video service.|
 313 | |authToken|String| 5.2.0 | Included exclusively when communicating with cloud applications. This token is used by a cloud application to authenticate a user account associated with the vehicle. |
 314 | |make|String| 5.4.0 | Vehicle make value. Used by OEM exclusive apps to identify whether current vehicle is supported or not. |
 315 | |model|String| 5.4.0 | Vehicle model value. Used by OEM exclusive apps to identify whether current vehicle is supported or not. |
 316 | |modelYear|String| 5.4.0 | Vehicle model year value. Used by OEM exclusive apps to identify whether current vehicle is supported or not. |
 317 | |trim|String| 5.4.0 | Vehicle trim value. Used by OEM exclusive apps to identify whether current vehicle is supported or not. |
 318 | |systemSoftwareVersion|String| 5.4.0 | Vehicle system software version value. Can be specified in any format desired by the OEM. |
 319 | |systemHardwareVersion|String| 5.4.0 | Vehicle system hardware version value. Can be specified in any format desired by the OEM. |
 320 | 
 321 | **list of transport type strings**
 322 | 
 323 | | String | Description |
 324 | |--------|-------------|
 325 | | IAP\_BLUETOOTH | iAP over Bluetooth |
 326 | | IAP\_USB | iAP over USB where it is not possible to distinguish between host or device mode|
 327 | | IAP\_USB\_HOST\_MODE | iAP over USB, and the phone is running as host |
 328 | | IAP\_USB\_DEVICE\_MODE | iAP over USB, and the phone is running as device |
 329 | | IAP\_CARPLAY | iAP over Carplay wireless |
 330 | | SPP\_BLUETOOTH | Bluetooth SPP. |
 331 | | AOA\_USB | Android Open Accessory |
 332 | | TCP\_WIFI | TCP connection over Wi-Fi |
 333 | 
 334 | ###### 3.1.3.2.3 Start Service NAK
 335 | | Tag Name | Type | Introduced | Description |
 336 | |----------|------|------------|-------------|
 337 | | rejectedParams |String Array| 5.0.0 | An array of rejected parameters|
 338 | | reason | String | 5.3.0 | A string describing the reason of failure |
 339 | 
 340 | ###### 3.1.3.2.4 End Service
 341 | | Tag Name | Type | Introduced | Description |
 342 | |----------|------|------------|-------------|
 343 | |hashId|int32| 5.0.0 | Hash ID supplied in the `StartServiceACK` for this service type|
 344 | 
 345 | ###### 3.1.3.2.5 End Service ACK
 346 | 
 347 | ###### 3.1.3.2.6 End Service NAK
 348 | | Tag Name | Type | Introduced | Description |
 349 | |----------|------|------------|-------------|
 350 | | rejectedParams |String Array| 5.0.0 | An array of rejected parameters such as: [`hashId`] |
 351 | | reason | String | 5.3.0 | A string describing the reason of failure |
 352 | 
 353 | ##### 3.1.3.3 Audio Service
 354 | ###### 3.1.3.3.1 Start Service
 355 | >No parameters
 356 | 
 357 | ###### 3.1.3.3.2 Start Service ACK
 358 | | Tag Name | Type | Introduced | Description |
 359 | |----------|------|------------|-------------|
 360 | |mtu| int64 | 5.0.0 | Max transport unit to be used for this service. If not included the client should use the one set via the RPC service or protocol version default.|
 361 | 
 362 | ###### 3.1.3.3.3 Start Service NAK
 363 | | Tag Name | Type | Introduced | Description |
 364 | |----------|------|------------|-------------|
 365 | | rejectedParams |String Array| 5.0.0 | An array of rejected parameters such as: [`videoProtocol`, `videoCodec`] |
 366 | | reason | String | 5.3.0 | A string describing the reason of failure |
 367 | 
 368 | ###### 3.1.3.3.4 End Service
 369 | >No parameters
 370 | 
 371 | ###### 3.1.3.3.5 End Service ACK
 372 | >No parameters
 373 | 
 374 | ###### 3.1.3.3.6 End Service NAK
 375 | | Tag Name | Type | Introduced | Description |
 376 | |----------|------|------------|-------------|
 377 | | rejectedParams |String Array| 5.0.0 | An array of rejected parameters such as: [`hashId`] |
 378 | | reason | String | 5.3.0 | A string describing the reason of failure |
 379 | 
 380 | ##### 3.1.3.4 Video Service
 381 | 
 382 | ###### 3.1.3.4.1 Start Service
 383 | | Tag Name | Type | Introduced | Description |
 384 | |----------|------|------------|-------------|
 385 | |height|int32| 5.0.0 | Desired height from the client requesting the video service to start|
 386 | |width|int32| 5.0.0 | Desired width from the client requesting the video service to start|
 387 | |videoProtocol|String| 5.0.0 | Desired video protocol to be used. See `VideoStreamingProtocol ` RPC|
 388 | |videoCodec|String| 5.0.0 | Desired video codec to be used. See `VideoStreamingCodec` RPC|
 389 | 
 390 | ###### 3.1.3.4.2 Start Service ACK
 391 | | Tag Name | Type | Introduced | Description |
 392 | |----------|------|------------|-------------|
 393 | |mtu| int64 | 5.0.0 | Max transport unit to be used for this service. If not included the client should use the one set via the RPC service or protocol version default.|
 394 | |height|int32| 5.0.0 | Accepted height from the client requesting the video service to start|
 395 | |width|int32| 5.0.0 | Accepted width from the client requesting the video service to start|
 396 | |videoProtocol|String| 5.0.0 | Accepted video protocol to be used. See `VideoStreamingProtocol ` RPC|
 397 | |videoCodec|String| 5.0.0 | Accepted video codec to be used. See `VideoStreamingCodec` RPC|
 398 | 
 399 | 
 400 | ###### 3.1.3.4.3 Start Service NAK
 401 | | Tag Name | Type | Introduced | Description |
 402 | |----------|------|------------|-------------|
 403 | | rejectedParams |String Array| 5.0.0 | An array of rejected parameters such as: [`videoProtocol`, `videoCodec`] |
 404 | | reason | String | 5.3.0 | A string describing the reason of failure |
 405 | 
 406 | ###### 3.1.3.4.4 End Service
 407 | >No parameters
 408 | 
 409 | ###### 3.1.3.4.5 End Service ACK
 410 | >No parameters
 411 | 
 412 | ###### 3.1.3.4.6 End Service NAK
 413 | | Tag Name | Type | Introduced | Description |
 414 | |----------|------|------------|-------------|
 415 | | rejectedParams |String Array| 5.0.0 | An array of rejected parameters such as: [`hashId`] |
 416 | | reason | String | 5.3.0 | A string describing the reason of failure |
 417 | 
 418 | 
 419 | 
 420 | ### 3.2 Single Frame
 421 | A frame of type Single Frame contains all the data for a particular packet in the payload. The majority of frames sent over the protocol utilize this frame type.
 422 | 
 423 | <table width="100%">
 424 |   <tr>
 425 |   	<th colspan = "2" align="center">Single Frame</th>
 426 |   </tr>
 427 |   <tr>
 428 |     <td width="10%">Header</td>
 429 |     <td>Payload</td>
 430 |   </tr>
 431 |   <tr>
 432 |     <td width="20%" style="visibility:hidden;"></td>
 433 |     <td align="center">Data</td>
 434 |   </tr>
 435 | </table>
 436 | 
 437 | #### 3.2.1 Special Header Definitions:
 438 | 
 439 | | Header Value |Expected values| Description |
 440 | |--------------|---------------|-------------|
 441 | |Frame Info| `0x00`|Reserved|
 442 | |Data Size| 0x01-0xFFFFFFFF|Total payload size in bytes for this frame|
 443 |  
 444 | ### 3.3 Multiple Frame Packets
 445 | Some payloads will be larger than the maximum transport unit will allow. If that is the case, the payload will be broken up over multiple frames. These frame types are First and Consecutive. 
 446 | 
 447 | <table width="100%">
 448 |   <tr style="visibility:hidden;">
 449 |     <td width="5%"></td>
 450 |     <td width="5%"></td>
 451 |     <td width="5%"></td>
 452 |     <td ></td>
 453 |     <td width="5%"></td>
 454 |     <td></td>
 455 |     <td width="5%"></td>
 456 |     <td></td>
 457 |     <td width="5%"></td>
 458 |     <td></td>
 459 |     <td></td>
 460 |   </tr>
 461 |     <tr>
 462 |     <td style="visibility:hidden;" colspan="3"></td>
 463 |     <td align="center" colspan="100%">Data</td>
 464 |   </tr>
 465 |   <tr>
 466 |   <td style="visibility:hidden;" colspan ="3"></td>
 467 |     <td align="center" colspan="2">Data Chunk 1 </td>
 468 |     <td align="center" colspan="2">Data Chunk 2 </td>
 469 |     <td style="border:0; background-color:white;" align="center" colspan="2">...</td>
 470 |     <td align="center" colspan="2">Data Chunk n </td>
 471 |   </tr>  
 472 |   <tr>
 473 |   	<th colspan = "2" align="center">First Frame</th>
 474 |   </tr>
 475 |   <tr>
 476 |     <td> Header</td>
 477 |     <td colspan = "1" >Payload</td>
 478 |   </tr>
 479 |   
 480 |   <tr>
 481 |      <th colspan = "2" style="visibility:hidden;"></th>
 482 |      <th colspan = "3">Consecutive Frame 1</th>
 483 |   </tr>
 484 |   <tr>
 485 |    <td colspan="2" style="visibility:hidden;"></td>
 486 | 	<td>Header</td>
 487 | 	<td colspan = "2" >Payload</td>  
 488 |   </tr>
 489 |   <tr>
 490 |      <th colspan = "4" style="visibility:hidden;"></th>
 491 |      <th colspan = "3">Consecutive Frame 2</th>
 492 |   </tr>
 493 |   <tr>
 494 |    <td colspan="4" style="visibility:hidden;"></td>
 495 | 	<td>Header</td>
 496 | 	<td colspan = "2" >Payload</td>  
 497 |   </tr>
 498 |   
 499 |   <tr style="border:0;">
 500 |      <td colspan = "7" style="visibility:hidden; border:0;"></td>
 501 |      <td style="font-size:25px; border:0; background-color:white;" align="center">...</td>
 502 |   </tr>
 503 |   <tr></tr>
 504 |   <tr>
 505 |      <th colspan = "8" style="visibility:hidden;"></th>
 506 |      <th colspan = "3">Consecutive Frame n</th>
 507 |   </tr>
 508 |   <tr>
 509 |    <td colspan="8" style="visibility:hidden;"></td>
 510 | 	<td>Header</td>
 511 | 	<td colspan = "2" >Payload</td>  
 512 |   </tr>
 513 | 
 514 | </table> 
 515 | 
 516 | 
 517 | #### 3.3.1 First Frame
 518 | The First Frame in a multiple frame payload contains information about the entire sequence of frames so that the receiving end can correctly parse all the frames and reassemble the entire payload. The payload of this frame is only eight bytes and contains information regarding the rest of the sequence.
 519 | 
 520 | ##### 3.3.1.1 Payload:
 521 | 
 522 | <table width = "100%">
 523 | 	<tr align="center">
 524 | 		<th>Byte</th>
 525 | 		<td width = "10%">0</td>
 526 | 		<td width = "10%">1</td>
 527 | 		<td width = "10%">2</td>
 528 | 		<td width = "10%">3</td>
 529 | 		<td width = "10%">4</td>
 530 | 		<td width = "10%">5</td>
 531 | 		<td width = "10%">6</td>
 532 | 		<td width = "10%">7</td>
 533 | 	</tr>
 534 | 	<tr align="center">
 535 | 		<td style="visibility:hidden;"></td>
 536 | 		<td colspan ="4" >Total size of the original payload being parsed</td>
 537 | 		<td colspan ="4" >Number of Consecutive Frames in this sequence</td>
 538 | 	</tr>
 539 | </table>
 540 | 
 541 | ##### 3.3.1.2 Special Header Definitions:
 542 | 
 543 | | Header Value |Expected values| Description |
 544 | |--------------|---------------|-------------|
 545 | |Frame Info| `0x00`|Reserved|
 546 | |Data Size| `0x08`|This frame contains a fixed data size (8 bytes) for the payload.|
 547 | 
 548 | #### 3.3.2 Consecutive Frame
 549 | The Consecutive Frames in a multiple frame payload contain the actual raw data of the original payload. The parsed payload contained in each of the Consecutive Frames' payloads should be buffered until the entire sequence is complete. 
 550 | 
 551 | ##### 3.3.2.1 Special Header Definitions:
 552 | 
 553 | | Header Value |Expected values| Description |
 554 | |--------------|---------------|-------------|
 555 | |Frame Info| `0x00` - `0xFF`|Values `0x01` - `0xFF` are used incrementally as each consecutive frame is created and sent in the sequence. eg The first consecutive packet in the sequence will have the value `0x01`, the next consecutive frame that contains the next chunk of data in the sequence will have the value `0x02`. <br><br>If the sequence reaches `0xFF` with more frames to create, it shall rollover to `0x01` **not** `0x00` as it is reserved. <br><br>`0x00` is only used for the last consecutive frame in a multi-frame sequence and the last frame must have this value.|
 556 | |Data Size| `0x01` - `0xFFFFFFFF`|Payload size in bytes for only this frame |
 557 | 
 558 | ## 4. Establishing Communication
 559 | 
 560 | ### 4.1 Transport Layer
 561 | >Required: All Protocol Versions
 562 | 
 563 | A physical transport must be established between a head unit and an application before an SDL session can start. 
 564 | 
 565 | ### 4.2 Version Negotiation
 566 | >Required: All Protocol Versions
 567 | 
 568 | #### 4.2.1 Overview
 569 | Once a physical transport is established, each application must negotiate the maximum supported protocol version with the head unit. To establish basic communication and register with the head unit, the application must start an RPC service (Service Type: 0x07), using a *Version 1 Protocol Header*.
 570 | 
 571 | There are two types of version negotiation. Protocol versions 1 through 4 use an old style of negotiation, where as versions 5 and newer use a faster and more intelligent negotiation scheme.
 572 | 
 573 | ##### 4.2.1.1 Version 1-4 Negotiation
 574 | >Required for Protocol Versions 1 through 4
 575 | 
 576 | | Proxy| Direction | Core |
 577 | |------------|------|-------------|
 578 | |`StartService`<br> **Version:** v1 <br> **Payload:** no payload| ----------->|
 579 | || <-----------|`StartServiceACK`<br> **Version:** Max supported by Core<br> **Payload:** raw bytes for hashID
 580 | |`SingleFrame` *(or other RPC supporting Frame Type)* <br> **Version:** Highest version supported by both Core and Proxy <br> **Payload:** Lots of bytes| ----------->| Sets negotiated version. 
 581 | 
 582 | ##### 4.2.1.2 Version 5+ Negotiation
 583 | >Required for Protocol Versions 5 and newer
 584 | 
 585 | | Proxy| Direction | Core |
 586 | |------------|------|-------------|
 587 | |`StartService`<br> **Version:** v1 <br> **Payload:** Constructed payload [protocolVersion: 5.x.x]| ----------->| **v4 Core**: Ignores payload, sends protocol version 4 frame and uses previous negotiation scheme. <br> **v5+ Core:** Reads in payload data, uses this information to determine version. 
 588 | || <-----------|`StartServiceACK`<br> **Version:** Highest version supported by both Core and Proxy<br> **Payload:** Constructed payload [protocolVersion: 5.x.x, hashId: 0x9873, mtu: 130687]
 589 | |`SingleFrame`<br> **Version:** Highest version supported by both Core and Proxy <br> **Payload:** Lots of bytes| ----------->|
 590 | 
 591 | #### 4.2.2 Starting Communication
 592 | The application sends a `StartService` frame to the module containing no payload.
 593 | 
 594 | ##### Application -> Head Unit
 595 | 
 596 | #### 4.2.2.1 Versions 1 - 4
 597 | 
 598 | <table width="100%">
 599 |   <tr>
 600 |     <th>Version</th>
 601 |     <th>C</th>
 602 |     <th>Frame Type</th>
 603 |     <th>Service Type</th>
 604 |     <th>Frame Info</th>
 605 |     <th>Session Id</th>
 606 |     <th>Data Size</th>
 607 |   </tr>
 608 |   <tr>
 609 |     <td>1</td>
 610 |     <td>no</td>
 611 |     <td>Control</td>
 612 |     <td>RPC</td>
 613 |     <td>Start Service</td>
 614 |     <td>0</td>
 615 |     <td>0</td>
 616 |   </tr>
 617 |   <tr>
 618 |     <td>0b0001</td>
 619 |     <td>0b0</td>
 620 |     <td>0b000</td>
 621 |     <td>0x07</td>
 622 |     <td>0x01</td>
 623 |     <td>0x00</td>
 624 |     <td>0x00000000</td>
 625 |   </tr>
 626 | </table>
 627 | 
 628 | #### 4.2.2.2 Versions 5 and newer
 629 | >**Note:** Even though this is a Protocol Version 1 frame header it includes a payload. This is a very special exception.
 630 | 
 631 | Payload includes a constructed BSON object that has a single parameter of `protocolVersion` that describes the applications max supported Protocol Version.
 632 | 
 633 | <table width="100%">
 634 |   <tr>
 635 |     <th>Version</th>
 636 |     <th>C</th>
 637 |     <th>Frame Type</th>
 638 |     <th>Service Type</th>
 639 |     <th>Frame Info</th>
 640 |     <th>Session Id</th>
 641 |     <th>Data Size</th>
 642 |   </tr>
 643 |   <tr>
 644 |     <td>1</td>
 645 |     <td>no</td>
 646 |     <td>Control</td>
 647 |     <td>RPC</td>
 648 |     <td>Start Service</td>
 649 |     <td>0</td>
 650 |     <td>Size of Payload</td>
 651 |   </tr>
 652 |   <tr>
 653 |     <td>0b0001</td>
 654 |     <td>0b0</td>
 655 |     <td>0b000</td>
 656 |     <td>0x07</td>
 657 |     <td>0x01</td>
 658 |     <td>0x00</td>
 659 |     <td>0xNNNNNNNN</td>
 660 |   </tr>
 661 |   </table>
 662 |   
 663 |   <table width=100% >
 664 |   <tr>
 665 |   	<th colspan="8">Payload</th>
 666 |   </tr>
 667 |   <tr align="center">
 668 |   	<td colspan="8" > [protocolVersion: x.x.x]</td>
 669 |   </tr>
 670 | </table>
 671 | 
 672 | #### 4.2.3 Success
 673 | If the head unit allows the RPC service to start, it will respond with a `StartServiceACK`. At this time the version will finish its negotiation process.
 674 | 
 675 | ##### Head Unit -> Application
 676 | 
 677 | ##### 4.2.3.1 Protocol Versions 1-4 
 678 | 
 679 | The `StartServiceACK` will contain the module's maximum supported protocol version. The packet structure will also match that of the supplied version; if the module's maximum supported version is 1, the packet will contain an 8 byte header (version 1), otherwise it will contain a 12 byte header (version 2). The application will then find the highest version supported by both the module and the application. This will be the determined version used for this session and will be used for all other packets sent from this point forward as well as all other services.
 680 | 
 681 | The payload of the `StartServiceACK` will contain a hash of the service which was started on the head unit if the payload size is greater than 0. This hash should be stored by an application and is needed in the end communication flow.
 682 | 
 683 | 
 684 | <table width="100%">
 685 |   <tr>
 686 |     <th>Version</th>
 687 |     <th>E</th>
 688 |     <th>Frame Type</th>
 689 |     <th>Service Type</th>
 690 |     <th>Frame Info</th>
 691 |     <th>Session Id</th>
 692 |     <th>Data Size</th>
 693 |     <th>Message ID</th>
 694 |   </tr>
 695 |   <tr>
 696 |     <td>Max Module Version (4)</td>
 697 |     <td>no</td>
 698 |     <td>Control</td>
 699 |     <td>RPC</td>
 700 |     <td>Start Service ACK</td>
 701 |     <td>Assigned Session</td>
 702 |     <td>4</td>
 703 |     <td>2</td>
 704 |   </tr>
 705 |   <tr>
 706 |     <td>0b0100</td>
 707 |     <td>0b0</td>
 708 |     <td>0b000</td>
 709 |     <td>0x07</td>
 710 |     <td>0x02</td>
 711 |     <td>0x01</td>
 712 |     <td>0x00000004</td>
 713 |     <td>0x0000000n</td>
 714 |   </tr>
 715 | </table>
 716 | 
 717 | ##### 4.2.3.2 Protocol Versions 5 and newer 
 718 | 
 719 | The `StartServiceACK` will contain a negotiated version between what the application provided in the `StartService` frame and what the module's maximum supported protocol version. Thus, if it is determined that no such information was sent in the `StartService` frame, the module will assume the previous method of version negotiation and send version 4 to assume it's max version supplied to the application and wait for the incoming `RegisterAppInterface` RPC from the application to finally determine the negotiated version. Either way, the determined version will be used for this session including all other packets sent from this point forward as well as all other services.
 720 | 
 721 | The packet structure will also match that of the supplied version; if the module's maximum supported version is 1, the packet will contain an 8 byte header (version 1), otherwise it will contain a 12 byte header (version 2). If the protocol version was determined to be 5 or higher, the payload it contains will be constructed in nature as a BSON object. The application will then find the highest version supported by both the module and the application. This will be the determined version used for this session and will be used for all other packets sent from this point forward as well as all other services.
 722 | 
 723 | The payload of the `StartServiceACK` will contain the agreed upon full protocol version *"Major.Minor.Patch"*, a hash of the service which was started on the head unit, and the max transport unit for that session (0x07 RPC). The hash should be stored by an application and is needed in the end communication flow. The MTU should be used as the default MTU for all other services for that session unless otherwise provided in the corresponding `StartServiceACK` for that service. 
 724 | 
 725 | ###### 4.2.3.2.1 Protocol Version Supplied in `StartService`
 726 | 
 727 | <table width="100%">
 728 |   <tr>
 729 |     <th>Version</th>
 730 |     <th>E</th>
 731 |     <th>Frame Type</th>
 732 |     <th>Service Type</th>
 733 |     <th>Frame Info</th>
 734 |     <th>Session Id</th>
 735 |     <th>Data Size</th>
 736 |     <th>Message ID</th>
 737 |   </tr>
 738 |   <tr>
 739 |     <td>Max major version supported by module and application </td>
 740 |     <td>no</td>
 741 |     <td>Control</td>
 742 |     <td>RPC</td>
 743 |     <td>Start Service ACK</td>
 744 |     <td>Assigned Session</td>
 745 |     <td>Size of payload</td>
 746 |     <td>2</td>
 747 |   </tr>
 748 |   <tr>
 749 |     <td>0bNNNN</td>
 750 |     <td>0b0</td>
 751 |     <td>0b000</td>
 752 |     <td>0x07</td>
 753 |     <td>0x02</td>
 754 |     <td>0x01</td>
 755 |     <td>0xNNNNNNNN</td>
 756 |     <td>0x0000000n</td>
 757 |   </tr>
 758 | </table>
 759 | 
 760 | <table width=100% >
 761 | 	<tr>
 762 |   		<th colspan="8">Payload</th>
 763 |   	</tr>
 764 |   	<tr align="center">
 765 |   		<td colspan="8" > [protocolVersion: x.x.x, hashId: 0xNNNN, mtu: 130687]</td
 766 |   	</tr>
 767 | </table>
 768 | 
 769 | ###### 4.2.3.2.2 Protocol Version Not Supplied  in `StartService`
 770 | 
 771 | <table width="100%">
 772 |   <tr>
 773 |     <th>Version</th>
 774 |     <th>E</th>
 775 |     <th>Frame Type</th>
 776 |     <th>Service Type</th>
 777 |     <th>Frame Info</th>
 778 |     <th>Session Id</th>
 779 |     <th>Data Size</th>
 780 |     <th>Message ID</th>
 781 |   </tr>
 782 |   <tr>
 783 |     <td>Max version application can possibly support (4)</td>
 784 |     <td>no</td>
 785 |     <td>Control</td>
 786 |     <td>RPC</td>
 787 |     <td>Start Service ACK</td>
 788 |     <td>Assigned Session</td>
 789 |     <td>4</td>
 790 |     <td>2</td>
 791 |   </tr>
 792 |   <tr>
 793 |     <td>0b0100</td>
 794 |     <td>0b0</td>
 795 |     <td>0b000</td>
 796 |     <td>0x07</td>
 797 |     <td>0x02</td>
 798 |     <td>0x01</td>
 799 |     <td>0x00000004</td>
 800 |     <td>0x0000000n</td>
 801 |   </tr>
 802 | </table>
 803 | 
 804 | 
 805 | ##### 4.2.4 Failure
 806 | If a session has already been started, or can't be started, a `StartServiceNAK` will be sent in response to the `StartService` packet.
 807 | 
 808 | ##### Head Unit -> Application
 809 | 
 810 | ##### 4.2.4.1 Protocol Versions 1 through 4
 811 | 
 812 | <table width="100%">
 813 |   <tr>
 814 |     <th>Version</th>
 815 |     <th>E</th>
 816 |     <th>Frame Type</th>
 817 |     <th>Service Type</th>
 818 |     <th>Frame Info</th>
 819 |     <th>Session Id</th>
 820 |     <th>Data Size</th>
 821 |     <th>Message ID</th>
 822 |   </tr>
 823 |   <tr>
 824 |     <td>Max Module Version (4)</td>
 825 |     <td>no</td>
 826 |     <td>Control</td>
 827 |     <td>RPC</td>
 828 |     <td>Start Service NAK</td>
 829 |     <td>0</td>
 830 |     <td>0</td>
 831 |     <td>0</td>
 832 |   </tr>
 833 |   <tr>
 834 |     <td>0b0100</td>
 835 |     <td>0b0</td>
 836 |     <td>0b000</td>
 837 |     <td>0x07</td>
 838 |     <td>0x03</td>
 839 |     <td>0x00</td>
 840 |     <td>0x00000000</td>
 841 |     <td>0x00000000</td>
 842 |   </tr>
 843 | </table>
 844 | 
 845 | ##### 4.2.4.1 Protocol Versions 5 and Newer
 846 | 
 847 | <table width="100%">
 848 |   <tr>
 849 |     <th>Version</th>
 850 |     <th>E</th>
 851 |     <th>Frame Type</th>
 852 |     <th>Service Type</th>
 853 |     <th>Frame Info</th>
 854 |     <th>Session Id</th>
 855 |     <th>Data Size</th>
 856 |     <th>Message ID</th>
 857 |   </tr>
 858 |   <tr>
 859 |     <td>Max Module Version (4)</td>
 860 |     <td>no</td>
 861 |     <td>Control</td>
 862 |     <td>RPC</td>
 863 |     <td>Start Service NAK</td>
 864 |     <td>0</td>
 865 |     <td>Size of Payload</td>
 866 |     <td>0</td>
 867 |   </tr>
 868 |   <tr>
 869 |     <td>0b0100</td>
 870 |     <td>0b0</td>
 871 |     <td>0b000</td>
 872 |     <td>0x07</td>
 873 |     <td>0x03</td>
 874 |     <td>0x00</td>
 875 |     <td>0xNNNNNNNN</td>
 876 |     <td>0x00000000</td>
 877 |   </tr>
 878 | </table>
 879 | 
 880 | <table width=100% >
 881 | 	<tr>
 882 |   		<th colspan="8">Payload</th>
 883 |   	</tr>
 884 |   	<tr align="center">
 885 |   		<td colspan="8" > [rejectedParams:[protocolVersion, x, x]]</td
 886 |   	</tr>
 887 | </table>
 888 | 
 889 | ##### 4.2.5 Start Service
 890 | 
 891 | The RPC service always needs to be started as unencrypted first, then it can be moved to an encrypted state by sending another `StartService` request containing an encryption flag set to `1` at a later point. Services of another type can be started as encrypted initially, i.e. it is not necessary to start them as unencrypted and then move to encrypted state using second `StartService` request (however such sequence of actions is also valid). See "7. Secured Communication" section for more details.
 892 | 
 893 | ### 4.3 Registration
 894 | >Required: All Protocol Versions
 895 | 
 896 | Each application registers for continued communication with the head unit by sending a `RegisterAppInterface` Request RPC to the head unit via the RPC Service. Additional services can only be started after a successful `RegisterAppInterface` Response RPC has been sent from the head unit to the application.
 897 | 
 898 | ### 4.4 Starting other services
 899 | While the RPC service is the default service that is started to establish a connection and a session, the application may wish to start other services. Similar to the process in Section 4, all services that are to be to started in a session require a `StartService` packet to be sent from the application. If the module supports and allows that service type to be started, it will respond with a `StartServiceACK` that has a payload of the hash ID for that service. If the module is unable to start that service or that application does not have access to that service, it will respond with a `StartServiceNAK`. 
 900 | 
 901 | ### 4.5 Heartbeat
 902 | >**Deprecated: Protocol Versions 4 and higher** <br>
 903 | >Required: Protocol Version 3<br>
 904 | >Added: Protocol Version 3
 905 | 
 906 | After a successful start service exchange between the application and head unit both the application and head unit are required to be able to respond to heartbeat messages if the negotiated protocol version is 3. After sending a heartbeat, if the application or head unit does not respond within a timeout (custom per app/head unit), the sender will disconnect. The sender's timer for the heartbeat timeout should be reset every time any message is received. Heartbeats are sent using the Control Service Type (0x00)
 907 | 
 908 | #### 4.5.1 Heartbeat Request
 909 | 
 910 | >Note: The request can originate from either the Head Unit or the Application
 911 | 
 912 | ##### Head Unit -> Application
 913 | 
 914 | <table width="100%">
 915 |   <tr>
 916 |     <th>Version</th>
 917 |     <th>E</th>
 918 |     <th>Frame Type</th>
 919 |     <th>Service Type</th>
 920 |     <th>Frame Info</th>
 921 |     <th>Session Id</th>
 922 |     <th>Data Size</th>
 923 |     <th>Message ID</th>
 924 |   </tr>
 925 |   <tr>
 926 |     <td>4</td>
 927 |     <td>no</td>
 928 |     <td>Control</td>
 929 |     <td>Control</td>
 930 |     <td>Heartbeat</td>
 931 |     <td>0</td>
 932 |     <td>0</td>
 933 |     <td>0</td>
 934 |   </tr>
 935 |   <tr>
 936 |     <td>0b0100</td>
 937 |     <td>0b0</td>
 938 |     <td>0b000</td>
 939 |     <td>0x00</td>
 940 |     <td>0x00</td>
 941 |     <td>0x00</td>
 942 |     <td>0x00000000</td>
 943 |     <td>0x00000000</td>
 944 |   </tr>
 945 | </table>
 946 | 
 947 | #### 4.5.2 Heartbeat ACK
 948 | 
 949 | >Note: The response ACK will originate from the Head Unit or the Application based on the origin of the request
 950 | 
 951 | ##### Application -> Head Unit
 952 | 
 953 | <table width="100%">
 954 |   <tr>
 955 |     <th>Version</th>
 956 |     <th>E</th>
 957 |     <th>Frame Type</th>
 958 |     <th>Service Type</th>
 959 |     <th>Frame Info</th>
 960 |     <th>Session Id</th>
 961 |     <th>Data Size</th>
 962 |     <th>Message ID</th>
 963 |   </tr>
 964 |   <tr>
 965 |     <td>4</td>
 966 |     <td>no</td>
 967 |     <td>Control</td>
 968 |     <td>Control</td>
 969 |     <td>Heartbeat ACK</td>
 970 |     <td>0</td>
 971 |     <td>0</td>
 972 |     <td>0</td>
 973 |   </tr>
 974 |   <tr>
 975 |     <td>0b0100</td>
 976 |     <td>0b0</td>
 977 |     <td>0b000</td>
 978 |     <td>0x00</td>
 979 |     <td>0xFF</td>
 980 |     <td>0x00</td>
 981 |     <td>0x00000000</td>
 982 |     <td>0x00000000</td>
 983 |   </tr>
 984 | </table>
 985 | 
 986 | #### 4.5.3 Heartbeat NAK
 987 | There is currently no heartbeat NAK.
 988 | 
 989 | ### 4.6 Secondary Transport
 990 | 
 991 | >Added: Protocol version 5.1.0
 992 | 
 993 | After the RPC service has been established on an initial transport, it is possible to utilize a different transport beyond the initial transport for certain services.  This additional transport is called the "Secondary Transport". The initial transport used to start the RPC service is called the "Primary Transport".
 994 | 
 995 | #### 4.6.1 Secondary Transport Registration
 996 | 
 997 | The RPC `StartServiceACK` will include information on potential Secondary Transports in the parameter `secondaryTransports` if any are supported. Once received, it is possible to register the session on the Secondary Transport if connected; if the transport is not connected it will have to either wait until an update is received through the `TransportEventUpdated` frame or the physical connection is made.
 998 | 
 999 | Once the connection for Secondary Transport is established, if the application wishes to utilize that transport as a SecondaryTransport, the application is required to send a `RegisterSecondaryTransport` frame on that transport. The head unit will respond with either a`RegisterSecondaryTransportACK` or `RegisterSecondaryTransportNAK` frame. If the registration was successful and the application receives a `RegisterSecondaryTransportACK`, it may then utilize the Secondary Transport to start services.
1000 | 
1001 | ##### 4.6.1.1 RegisterSecondaryTransport
1002 | 
1003 | ##### Application -> Head Unit
1004 | 
1005 | <table width="100%">
1006 |   <tr>
1007 |     <th>Version</th>
1008 |     <th>E</th>
1009 |     <th>Frame Type</th>
1010 |     <th>Service Type</th>
1011 |     <th>Frame Info</th>
1012 |     <th>Session Id</th>
1013 |     <th>Data Size</th>
1014 |     <th>Message ID</th>
1015 |   </tr>
1016 |   <tr>
1017 |     <td>Max major version supported by module and application</td>
1018 |     <td>no</td>
1019 |     <td>Control</td>
1020 |     <td>Control</td>
1021 |     <td>Register Secondary Transport</td>
1022 |     <td>Session Id assigned on Primary Transport</td>
1023 |     <td>0</td>
1024 |     <td>1</td>
1025 |   </tr>
1026 |   <tr>
1027 |     <td>0bNNNN</td>
1028 |     <td>0b0</td>
1029 |     <td>0b000</td>
1030 |     <td>0x00</td>
1031 |     <td>0x07</td>
1032 |     <td>0xNN</td>
1033 |     <td>0x00000000</td>
1034 |     <td>0x00000001</td>
1035 |   </tr>
1036 | </table>
1037 | 
1038 | ##### 4.6.1.2 RegisterSecondaryTransportACK
1039 | 
1040 | ##### Head Unit -> Application
1041 | 
1042 | <table width="100%">
1043 |   <tr>
1044 |     <th>Version</th>
1045 |     <th>E</th>
1046 |     <th>Frame Type</th>
1047 |     <th>Service Type</th>
1048 |     <th>Frame Info</th>
1049 |     <th>Session Id</th>
1050 |     <th>Data Size</th>
1051 |     <th>Message ID</th>
1052 |   </tr>
1053 |   <tr>
1054 |     <td>Max major version supported by module and application</td>
1055 |     <td>no</td>
1056 |     <td>Control</td>
1057 |     <td>Control</td>
1058 |     <td>Register Secondary Transport ACK</td>
1059 |     <td>Session Id assigned on Primary Transport</td>
1060 |     <td>0</td>
1061 |     <td>2</td>
1062 |   </tr>
1063 |   <tr>
1064 |     <td>0bNNNN</td>
1065 |     <td>0b0</td>
1066 |     <td>0b000</td>
1067 |     <td>0x00</td>
1068 |     <td>0x08</td>
1069 |     <td>0xNN</td>
1070 |     <td>0x00000000</td>
1071 |     <td>0x00000002</td>
1072 |   </tr>
1073 | </table>
1074 | 
1075 | ##### 4.6.1.3 RegisterSecondaryTransportNAK
1076 | 
1077 | ##### Head Unit -> Application
1078 | 
1079 | <table width="100%">
1080 |   <tr>
1081 |     <th>Version</th>
1082 |     <th>E</th>
1083 |     <th>Frame Type</th>
1084 |     <th>Service Type</th>
1085 |     <th>Frame Info</th>
1086 |     <th>Session Id</th>
1087 |     <th>Data Size</th>
1088 |     <th>Message ID</th>
1089 |   </tr>
1090 |   <tr>
1091 |     <td>Max major version supported by module and application if known, otherwise 5</td>
1092 |     <td>no</td>
1093 |     <td>Control</td>
1094 |     <td>Control</td>
1095 |     <td>Register Secondary Transport NAK</td>
1096 |     <td>Session Id assigned on Primary Transport</td>
1097 |     <td>0</td>
1098 |     <td>2</td>
1099 |   </tr>
1100 |   <tr>
1101 |     <td>0bNNNN</td>
1102 |     <td>0b0</td>
1103 |     <td>0b000</td>
1104 |     <td>0x00</td>
1105 |     <td>0x09</td>
1106 |     <td>0xNN</td>
1107 |     <td>0x00000000</td>
1108 |     <td>0x00000002</td>
1109 |   </tr>
1110 | </table>
1111 | 
1112 | 
1113 | #### 4.6.2 Transport Event Update
1114 | 
1115 | Some Secondary Transports might require additional details on how they can be established. For example, in order to establish a TCP connection between the application and head unit the IP address and port number are required. The `TransportEventUpdate` control frame is used for this purpose. 
1116 | 
1117 | The head unit will send out a `TransportEventUpdate` frame whenever its transport configuration is changed, for example when its IP address is updated or Wi-Fi network goes down. The head unit will also send out a `TransportEventUpdate` frame right after the `StartServiceACK` frame that establishes the RPC service so the application can initiate a connection immediately.
1118 | 
1119 | The `TransportEventUpdate` frame must always be sent through the Primary Transport. The head unit should not send the frame to applications that don't support protocol versions 5.1.0 or newer.
1120 | 
1121 | ##### 4.6.2.1 TransportEventUpdate
1122 | 
1123 | ##### Head Unit -> Application
1124 | 
1125 | <table width="100%">
1126 |   <tr>
1127 |     <th>Version</th>
1128 |     <th>E</th>
1129 |     <th>Frame Type</th>
1130 |     <th>Service Type</th>
1131 |     <th>Frame Info</th>
1132 |     <th>Session Id</th>
1133 |     <th>Data Size</th>
1134 |     <th>Message ID</th>
1135 |   </tr>
1136 |   <tr>
1137 |     <td>Max major version supported by module and application</td>
1138 |     <td>no</td>
1139 |     <td>Control</td>
1140 |     <td>Control</td>
1141 |     <td>Transport Event Update</td>
1142 |     <td>Session Id assigned on Primary Transport</td>
1143 |     <td>Size of payload</td>
1144 |     <td>Variable</td>
1145 |   </tr>
1146 |   <tr>
1147 |     <td>0bNNNN</td>
1148 |     <td>0b0</td>
1149 |     <td>0b000</td>
1150 |     <td>0x00</td>
1151 |     <td>0xFD</td>
1152 |     <td>0xNN</td>
1153 |     <td>0xNNNNNNNN</td>
1154 |     <td>0xNNNNNNNN</td>
1155 |   </tr>
1156 | </table>
1157 | 
1158 | <table width=100% >
1159 | 	<tr>
1160 |   		<th colspan="8">Payload</th>
1161 |   	</tr>
1162 |   	<tr align="center">
1163 |   		<td colspan="8" > [tcpIpAddress:"x.x.x.x", tcpPort:NNNN]</td
1164 |   	</tr>
1165 | </table>
1166 | 
1167 | #### 4.6.3 Starting Services on Secondary Transports
1168 | 
1169 | A Secondary Transport is capable of carrying  the video and audio services. Other services, including RPC and Hybrid service, must always run on the Primary Transport. (Note: Control service is an inherently started service on a transport and does not need to be established, but frames will be handled on a frame by frame basis of Primary vs Secondary Transport support)
1170 | 
1171 | The RPC `StartServiceACK` might include the parameters `audioServiceTransports` and `videoServiceTransports` describing which service is allowed to run on which transport priority type (Primary, Secondary or both). An application honors this information and starts the service(s) only on an allowed transport. For example, if video service is allowed only on a Secondary Transport, the application will not start video streaming until Secondary Transport is established and registered.
1172 | 
1173 | The transport priority types included in these parameters are listed in preferred order, for example, `[2,1]` (Secondary , Primary). In this case the priority of the Secondary Transport is higher than that of Primary Transport, the application may stop and restart service(s) when the Secondary Transport is added or removed. However,  each service type must only be started and carried on a single transport at a time. 
1174 | 
1175 | When starting a service over a Secondary Transport the application, it must follow the previous sections to establish the transport connection and register its session over that transport. At that point it runs the normal sequence described in section 4.4. When starting a service over a Secondary Transport, the session ID that was provided during the establishment of the RPC service should be used.
1176 | 
1177 | #### 4.6.4 Terminating Secondary Transport
1178 | 
1179 | There is no procedure to terminate a Secondary Transport. However, if the Primary Transport is disconnected or the RPC service is stopped, any Secondary Transport for that session should be unregistered and if no other sessions are registered over that Secondary Transport it should be disconnected.
1180 | 
1181 | ## 5. Services
1182 | Every active session has the ability to start any of the services defined in this protocol spec as long as they have permission on the module in which they are connected. Every session can only have one of each type of service open at a time. 
1183 |  
1184 | Messages sent have a priority based on their Service Type. Lower values for service type have higher delivery priority. A message's payload's format is based on the different service types defined below.
1185 | 
1186 | ### 5.1 Control Service
1187 | >Required: All Protocol Versions
1188 | 
1189 | The control service is the lowest level service available. While Control Frame packets are used frequently, the control service itself is rarely used.
1190 | 
1191 | #### 5.1.1 Security Query
1192 | 
1193 | When establishing a secure connection, the TLS Payload is sent in a control service message with a binary query header. The size of this header is 12 bytes, similar to the RPC Payload Binary Header.
1194 | 
1195 | ##### 5.1.1.1 Payload
1196 | 
1197 | The security query is able to contain JSON data as well as binary data. During the handshake the TLS handshake data is sent as binary data. See "Send Handshake Data" section for details.
1198 | 
1199 | In case of an error, a notification is sent with an error code and error message as JSON data. See "Send Internal Error" section for details.
1200 | 
1201 | <table width="100%">
1202 |   <tr><td align="center">Binary Query Header</td></tr>
1203 |   <tr><td align="center">JSON Data</td></tr>
1204 |   <tr><td align="center">Binary Data</td></tr>
1205 | </table>
1206 | 
1207 | ##### 5.1.1.2 Binary Header
1208 | 
1209 | <table width="100%">
1210 |   <tr>
1211 |     <th width="25%">Byte 1</th>
1212 |     <th width="25%">Byte 2</th>
1213 |     <th width="25%">Byte 3</th>
1214 |     <th width="25%">Byte 4</th>
1215 |   </tr>
1216 |   <tr>
1217 |     <td>Query Type</td>
1218 |     <td colspan="3" align="center">Query ID</td>
1219 |   </tr>
1220 |   <tr>
1221 |     <td colspan="4" align="center">Sequential Number</td>
1222 |   </tr>
1223 |   <tr>
1224 |     <td colspan="4" align="center">JSON Size</td>
1225 |   </tr>
1226 | </table>
1227 | 
1228 | ###### 5.1.1.2.1 Binary Header Fields
1229 | 
1230 | <table width="100%">
1231 |   <tr>
1232 |     <th>Field</th>
1233 |     <th>Size</th>
1234 |     <th>Description</th>
1235 |   </tr>
1236 |   <tr>
1237 |     <td>Query Type</td>
1238 |     <td>8 bit</td>
1239 |     <td>
1240 |       0x00 Request <br>
1241 |       0x01 - 0x0F Reserved<br>
1242 |       0x10 Response<br>
1243 |       0x11 - 0x1F Reserved<br>
1244 |       0x20 Notification<br>
1245 |       0x21 - 0xFE Reserved<br>
1246 |       0xFF Invalid Query Type
1247 |     </td>
1248 |   </tr>
1249 |   <tr>
1250 |     <td>Query ID</td>
1251 |     <td>24 bit</td>
1252 |     <td>
1253 |       0x000001 Send Handshake Data<br>
1254 |       0x000002 Send Internal Error<br>
1255 |       0x000003 - 0xFFFFFE Reserved<br>
1256 |       0xFFFFFF Invalid Query ID
1257 |     </td>
1258 |   </tr>
1259 |   <tr>
1260 |     <td>Sequential Number</td>
1261 |     <td>32 bit</td>
1262 |     <td>
1263 |       Message ID can be set by the mobile libraries to track security messages.<br>
1264 |       The system uses the same Message ID when replying to the query allowing the mobile libraries to correlate messages.
1265 |     </td>
1266 |   </tr>
1267 |   <tr>
1268 |     <td>JSON Size</td>
1269 |     <td>32 bit</td>
1270 |     <td>
1271 |       The size of the JSON data following the binary query header.<br>
1272 |       Any additional data following the JSON data in the payload is binary data.
1273 |     </td>
1274 |   </tr>
1275 | </table>
1276 | 
1277 | ##### 5.1.1.3 Send Handshake Data
1278 | 
1279 | When performing the TLS handshake, the server sends a "Send Handshake Data" request containing its handshake data to the client, and the client sends a response with its own handshake data accordingly.
1280 | 
1281 | ###### 5.1.1.3.1 Request Payload
1282 | 
1283 | **Note:** Prior to SDL Core version 8.0.0, Core sent the "Notification" type (`0x20`) in this message instead of "Request" (`0x00`). Client libraries should account for this when communicating with older versions of SDL Core.
1284 | 
1285 | <table width="100%">
1286 |   <tr>
1287 |     <th colspan="4">Binary Query Header</th>
1288 |   <tr>
1289 |   <tr>
1290 |     <th>Query Type</th>
1291 |     <th>TLS Message Type</th>
1292 |     <th>Sequential Number</th>
1293 |     <th>JSON Size</th>
1294 |   </tr>
1295 |   <tr>
1296 |     <td>Request</td>
1297 |     <td>Send Handshake Data</td>
1298 |     <td>Any number to be used to correlate query messages</td>
1299 |     <td>Zero</td>
1300 |   </tr>
1301 |   <tr>
1302 |     <td>0x00</td>
1303 |     <td>0x000001</td>
1304 |     <td>0xNNNNNNNN</td>
1305 |     <td>0x00000000</td>
1306 |   </tr>
1307 |   <tr>
1308 |     <th align="center" colspan="4">Binary Data: SSL Handshake Request</td>
1309 |   </tr>
1310 | </table>
1311 | 
1312 | ###### 5.1.1.3.2 Response Payload
1313 | <table width="100%">
1314 |   <tr>
1315 |     <th colspan="4">Binary Query Header</th>
1316 |   <tr>
1317 |   <tr>
1318 |     <th>Query Type</th>
1319 |     <th>TLS Message Type</th>
1320 |     <th>Sequential Number</th>
1321 |     <th>JSON Size</th>
1322 |   </tr>
1323 |   <tr>
1324 |     <td>Response</td>
1325 |     <td>Send Handshake Data</td>
1326 |     <td>Any number to be used to correlate query messages</td>
1327 |     <td>Zero</td>
1328 |   </tr>
1329 |   <tr>
1330 |     <td>0x10</td>
1331 |     <td>0x000001</td>
1332 |     <td>0xNNNNNNNN</td>
1333 |     <td>0x00000000</td>
1334 |   </tr>
1335 |   <tr>
1336 |     <th align="center" colspan="4">Binary Data: SSL Handshake Response</td>
1337 |   </tr>
1338 | </table>
1339 | 
1340 | #### 5.1.1.4 Send Internal Error
1341 | 
1342 | If an error occurs during the TLS handshake, a notification is sent with both JSON data and binary data describing the error. The JSON data contains the error code and an error text. The binary data is one single byte and only contains the error code.
1343 | 
1344 | The error code in JSON data and the binary data are the same value from the same code list.
1345 | 
1346 | ##### 5.1.1.4.1 Payload
1347 | 
1348 | The following query header is used by the system and the application to send error messages.
1349 | 
1350 | <table width="100%">
1351 |   <tr>
1352 |     <th colspan="4">Binary Query Header</th>
1353 |   <tr>
1354 |   <tr>
1355 |     <th>Query Type</th>
1356 |     <th>TLS Message Type</th>
1357 |     <th>Sequential Number</th>
1358 |     <th>JSON Size</th>
1359 |   </tr>
1360 |   <tr>
1361 |     <td>Notification</td>
1362 |     <td>Send Internal Error</td>
1363 |     <td>Unused</td>
1364 |     <td>Size of the JSON data</td>
1365 |   </tr>
1366 |   <tr>
1367 |     <td>0x20</td>
1368 |     <td>0x000002</td>
1369 |     <td>0xNNNNNNNN</td>
1370 |     <td>0xNNNNNNNN</td>
1371 |   </tr>
1372 |   <tr>
1373 |     <th colspan="4">JSON Data</th>
1374 |   </tr>
1375 |   <tr>
1376 |     <th colspan="4">Binary Data: Single Byte Error Code</th>
1377 |   </tr>
1378 | </table>
1379 | 
1380 | ##### 5.1.1.4.2 JSON structure
1381 | 
1382 | <table width="100%">
1383 |   <tr>
1384 |     <th>Key</th>
1385 |     <th>Description</th>
1386 |   </tr>
1387 |   <tr>
1388 |     <td>id</td>
1389 |     <td>A decimal value representing an Error code.</td>
1390 |   </tr>
1391 |   <tr>
1392 |     <td>text</td>
1393 |     <td>A string describing the error.</td>
1394 |   </tr>
1395 | </table>
1396 | 
1397 | ##### 5.1.1.4.3 Error codes
1398 | 
1399 | <table width="100%">
1400 |   <tr>
1401 |     <th>Error code</th>
1402 |     <th>Byte</th>
1403 |     <th>Value</th>
1404 |     <th>Description</th>
1405 |   </tr>
1406 |   <tr>
1407 |     <td>ERROR_SUCCESS</td>
1408 |     <td>0x00</td><td>0</td>
1409 |     <td>Internal Security Manager value</td>
1410 |   </tr>
1411 |   <tr>
1412 |     <td>ERROR_INVALID_QUERY_SIZE</td>
1413 |     <td>0x01</td><td>1</td>
1414 |     <td>Wrong size of query data</td>
1415 |   </tr>
1416 |   <tr>
1417 |     <td>ERROR_INVALID_QUERY_ID</td>
1418 |     <td>0x02</td><td>2</td>
1419 |     <td>Unknown Query ID</td>
1420 |   </tr>
1421 |   <tr>
1422 |     <td>ERROR_NOT_SUPPORTED</td>
1423 |     <td>0x03</td><td>3</td>
1424 |     <td>SDL does not support encryption</td>
1425 |   </tr>
1426 |   <tr>
1427 |     <td>ERROR_SERVICE_ALREADY_PROTECTED</td>
1428 |     <td>0x04</td><td>4</td>
1429 |     <td>Received request to protect a service that was protected before</td>
1430 |   </tr>
1431 |   <tr>
1432 |     <td>ERROR_SERVICE_NOT_PROTECTED</td>
1433 |     <td>0x05</td><td>5</td>
1434 |     <td>Received handshake or encrypted data for not protected service</td>
1435 |   </tr>
1436 |   <tr>
1437 |     <td>ERROR_DECRYPTION_FAILED</td>
1438 |     <td>0x06</td><td>6</td>
1439 |     <td>Decryption failed</td>
1440 |   </tr>
1441 |   <tr>
1442 |     <td>ERROR_ENCRYPTION_FAILED</td>
1443 |     <td>0x07</td><td>7</td>
1444 |     <td>Encryption failed</td>
1445 |   </tr>
1446 |   <tr>
1447 |     <td>ERROR_SSL_INVALID_DATA</td>
1448 |     <td>0x08</td><td>8</td>
1449 |     <td>SSL invalid data</td>
1450 |   </tr>
1451 |   <tr>
1452 |     <td>ERROR_HANDSHAKE_FAILED</td>
1453 |     <td>0x09</td><td>9</td>
1454 |     <td>In case of all other handshake errors</td>
1455 |   </tr>
1456 |   <tr>
1457 |     <td>INVALID_CERT</td>
1458 |     <td>0x0A</td><td>10</td>
1459 |     <td>Handshake failed because certificate is invalid</td>
1460 |   </tr>
1461 |   <tr>
1462 |     <td>EXPIRED_CERT</td>
1463 |     <td>0x0B</td><td>11</td>
1464 |     <td>Handshake failed because certificate is expired</td>
1465 |   </tr>
1466 |   <tr>
1467 |     <td>ERROR_INTERNAL</td>
1468 |     <td>0xFF</td><td>255</td>
1469 |     <td>Internal error</td>
1470 |   </tr>
1471 |   <tr>
1472 |     <td>ERROR_UNKNOWN_INTERNAL_ERROR</td>
1473 |     <td>0xFE</td><td>254</td>
1474 |     <td>Error value for testing</td>
1475 |   </tr>
1476 | </table>
1477 | 
1478 | ### 5.2 RPC Service
1479 | >Required: All Protocol Versions
1480 | 
1481 | The RPC service is used to send requests, responses, and notifications between an application and a head unit. Valid messages are defined in the [RPC Specification](https://github.com/smartdevicelink/sdl_core/blob/master/src/components/interfaces/MOBILE_API.xml).
1482 | 
1483 | The payload of a message sent via the RPC service, which directly follows the Frame Header in the packet, consists of a Binary Header, and JSON data representing the RPC.
1484 | 
1485 | ##### RPC Payload
1486 | 
1487 | <table>
1488 |   <tr>
1489 |     <td align="center" width="5000">Binary Header</td>
1490 |   </tr>
1491 |   <tr>
1492 |     <td align="center">JSON Data</td>
1493 |   </tr>
1494 | </table>
1495 | 
1496 | #### 5.2.1 Binary Header
1497 | >Required: Protocol Version 2 and greater
1498 | 
1499 | <table>
1500 |   <tr>
1501 |     <th colspan="2" width="25%">Byte 1</th>
1502 |     <th width="25%">Byte 2</th>
1503 |     <th width="25%">Byte 3</th>
1504 |     <th width="25%">Byte 4</th>
1505 |   </tr>
1506 |   <tr>
1507 |     <td width="12.5%">RPC Type</td>
1508 |     <td colspan="4" align="center">RPC Function ID</td>
1509 |   </tr>
1510 |   <tr>
1511 |     <td colspan="5" align="center">Correlation ID</td>
1512 |   </tr>
1513 |   <tr>
1514 |     <td colspan="5" align="center">JSON Size</td>
1515 |   </tr>
1516 | </table>
1517 | 
1518 | ##### 5.2.1.1 Binary Header Fields
1519 | 
1520 | <table>
1521 |   <tr>
1522 |     <th>Field</th>
1523 |     <th>Size</th>
1524 |     <th>Description</th>
1525 |   </tr>
1526 |   <tr>
1527 |     <td>RPC Type</td>
1528 |     <td>4 bit</td>
1529 |     <td>
1530 |       0x0 Request<br>
1531 |       0x1 Response<br>
1532 |       0x2 Notification<br>
1533 |       0x3 Erroneous Response<br>
1534 |       0x4 - 0xF Reserved
1535 |     </td>
1536 |   </tr>
1537 |   <tr>
1538 |     <td>RPC Function ID</td>
1539 |     <td>28 bit</td>
1540 |     <td>The Function ID of each RPC is specific to each version of the <a href="https://github.com/smartdevicelink/sdl_core/blob/develop/src/components/interfaces/MOBILE_API.xml#L2146-2207">RPC Specification</a> but in general do not change from version to version.
1541 |   </tr>
1542 |   <tr>
1543 |     <td>Correlation ID</td>
1544 |     <td>32 bits (signed)</td>
1545 |     <td>The Correlation ID is used to map a request to its response. Requests sent in the same session with the same Correlation ID as a pending request will be rejected with an `INVALID_ID` response. Requests that use a Correlation ID less than 0 will be rejected with an `INVALID_ID` response. In Protocol Version 1, when the Binary Header did not exist, the Correlation ID was included as part of the JSON and has a max value of 65536.</td>
1546 |   </tr>
1547 |   <tr>
1548 |     <td>JSON Size</td>
1549 |     <td>32 bits</td>
1550 |     <td>The size of the JSON Data following the Binary Header in the RPC Payload</td>
1551 |   </tr>
1552 | </table>
1553 | 
1554 | ### 5.3 Hybrid (Bulk Data) Service
1555 | >Required: Protocol Version 2 and greater
1556 | 
1557 | The Hybrid Service does not need to be explicitly started; all applications that have successfully started the RPC Service have access to the Hybrid Service.
1558 | 
1559 | The Hybrid Service is similar to the RPC Service but adds a bulk data field. The payload of a message sent via the Hybrid service consists of a Binary Header, JSON Data, and Bulk Data.
1560 | 
1561 | The size of the Bulk Data field is the Data Size (Found in the Frame Header) minus the 12 Bytes of the Binary Header minus the JSON Size (Found in the Binary Header).
1562 | 
1563 | The Binary Header of a message using the Hybrid Service is the same as the Binary Header of a message using the RPC Service.
1564 | 
1565 | ##### Hybrid Service Payload
1566 | 
1567 | <table>
1568 |   <tr>
1569 |     <td align="center" width="5000">Binary Header</td>
1570 |   </tr>
1571 |   <tr>
1572 |     <td align="center">JSON Data</td>
1573 |   </tr>
1574 |   <tr>
1575 |     <td align="center">Bulk Data</td>
1576 |   </tr>
1577 | </table>
1578 | 
1579 | ### 5.4 Audio Service (PCM)
1580 | >Available: Protocol Version 3 and greater
1581 | 
1582 | The application can start the audio service to send PCM audio data to the head unit. After the `StartService` packet is sent and the ACK received, the payload for the Audio Service is only PCM audio data.
1583 | 
1584 | ### 5.5 Video Service (H.264)
1585 | >Available: Protocol Version 3 and greater
1586 | 
1587 | The application can start the video service to send H.264 video data to the head unit. After the `StartService` packet is sent and the ACK received, the payload for the Video Service is only H.264 video data.
1588 | 
1589 | 
1590 | ## 6. Ending Communication
1591 | The application may request it's session to be ended outside of a transport disconnect, module power cycle, etc. 
1592 | ### 6.1 Completely Closing  a Session and Ending All Services
1593 | To close out a communication session with the head unit, an application sends an `EndService` packet with service type 7 (RPC) to the module. The `EndService` packet payload should include the correct hash ID supplied with the `StartServiceACK`. 
1594 | 
1595 | ### 6.2 Closing Specific Services
1596 | If the application doesn't want to completely stop its session, but only wishes to close a specific session it can do so using an `EndService` packet that's service type matches the service that the application is trying to close. The `EndService` packet should include the hash ID in its payload that was contained in the `StartServiceACK` for  that specific service.
1597 | 
1598 | ## 7. Secured Communication
1599 | 
1600 | It is possible to establish a secured and encrypted communication with the system by setting the frame header encryption flag to `1` when starting a new service or by sending another `StartService` with the encryption flag set to `1` when the service is already established (this the required flow for the RPC service). If the authentication is successful, the system will reply with a `StartService ACK` frame with the encryption flag also set to `1` indicating that encrypted data is now accepted. If the authentication fails for some reason, the system will reset the TLS connection and return a `StartService NAK` frame.
1601 | 
1602 | Below are possible combinations of the service encryption status and RPCs protection flag value.
1603 | 
1604 | <table width="100%">
1605 |   <tr>
1606 |     <th width="30%">Service Encryption Status</th>
1607 |     <th width="10%">RPC Type</th>
1608 |     <th width="10%">Requires Protection</th>
1609 |     <th width="50%">Expected SDL Behavior</th>
1610 |   </tr>
1611 |   <tr>
1612 |     <td rowspan="4">Encryption is not established</td>
1613 |     <td rowspan="2">Request</td>
1614 |     <td>yes</td>
1615 |     <td>SDL Core rejects the request with result code `ENCRYPTION_NEEDED` (please see policy updates for which RPCs need protection).</td>
1616 |   </tr> 
1617 |   <tr>
1618 |     <td>no</td>
1619 |     <td>SDL Core continues processing the RPC request.</td>
1620 |   </tr>
1621 |   <tr>
1622 |     <td rowspan="2">Notification</td>
1623 |     <td>yes</td>
1624 |     <td>SDL Core does not send the notification.</td>
1625 |   </tr> 
1626 |   <tr>
1627 |     <td>no</td>
1628 |     <td>SDL Core sends the notification unencrypted.</td>
1629 |   </tr>
1630 |   
1631 |   <tr>
1632 |     <td rowspan="4">Encryption is established</td>
1633 |     <td rowspan="2">Request</td>
1634 |     <td>yes</td>
1635 |     <td>
1636 |       If unencrypted, SDL Core rejects the request with an unencrypted response and result code `ENCRYPTION_NEEDED`.<br>
1637 |       If encrypted, SDL Core continues processing the request and sends an encrypted response.
1638 |     </td>
1639 |   </tr>
1640 |   <tr>
1641 |     <td>no</td>
1642 |     <td>
1643 |       If unencrypted, SDL Core continues processing the request and sends an unencrypted response.<br>
1644 |       If encrypted, SDL Core continues processing the request and sends an encrypted response.
1645 |     </td>
1646 |   </tr>
1647 |   <tr>
1648 |     <td rowspan="2">Notification</td>
1649 |     <td>yes</td>
1650 |     <td>SDL Core sends the notification encrypted.</td>
1651 |   </tr>
1652 |   <tr>
1653 |     <td>no</td>
1654 |     <td>SDL Core sends the notification unencrypted.</td>
1655 |   </tr>
1656 | 
1657 | </table>
1658 | 
1659 | ### 7.1 Authentication
1660 | 
1661 | The authentication is done using TLS handshake. The TLS handshake process is defined by TLS and is not part of the SDL protocol. 
1662 | 
1663 | The below diagram shows the sequence of how the TLS handshake exchanges certificates to compute the master secret.
1664 | 
1665 | ![TLS Handshake activity diagram](https://user-images.githubusercontent.com/5848997/122258220-cb8b7100-ce9e-11eb-9b2a-a6194b0d1b68.png)
1666 | 
1667 | Please see [SDL Overview Guides](https://smartdevicelink.com/en/guides/pull_request/sdl-overview-guides/security/protected-services/) for more details.
1668 | 
1669 | The system can be configured to support one encryption method. The following methods are supported:
1670 | 
1671 | - TLSv1
1672 | - TLSv1.1
1673 | - TLSv1.2
1674 | - DTLSv1
1675 | - SSLv3 (not supported on most newer systems)
1676 | 
1677 | The system has to initiate with the corresponding client method. For instance, if the system is configured to use `DTLSv1`, it has to use the method `DTLSv1_client`. The application role has to be server and must use `DTLSv1_server`.
1678 | 
1679 | The system also supports configurable [SSL Security level](https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_get_security_level.html) introduced in OpenSSL 1.1.0. This parameter can be changed by `SecurityLevel` parameter in the Core configuration file. By default, system uses security level 1 for TLS handshakes. At this time setting the security level higher than 1 for general internet use is likely to cause considerable interoperability issues and is not recommended. This is because the SHA1 algorithm is very widely used in certificates and will be rejected at levels higher than 1 because it only offers 80 bits of security.
1680 | 
1681 | ### 7.2 Handshake Frames
1682 | 
1683 | The system will initiate a TLS handshake to authenticate the application where the system's role will be the client while the application's role will be the server. The system will do this only once if the application was not authenticated before in the current transport connection. The TLS handshake data is always sent in single frames. The service type for TLS handshake is the control service. 
1684 | 
1685 | #### 7.2.1 SDL Protocol Frame Header
1686 | 
1687 | The following SDL frame header is used for every frame related to TLS handshake.
1688 | 
1689 | <table width="100%">
1690 |   <tr>
1691 |     <th colspan="8">SDL Protocol Frame Header</th>
1692 |   <tr>
1693 |   <tr>
1694 |     <th>Version</th>
1695 |     <th>E</th>
1696 |     <th>Frame Type</th>
1697 |     <th>Service Type</th>
1698 |     <th>Frame Info</th>
1699 |     <th>Session ID</th>
1700 |     <th>Data Size</th>
1701 |     <th>Message ID</th>
1702 |   </tr>
1703 |   <tr>
1704 |     <td>Max major version supported<br>by module and application</td>
1705 |     <td>no</td>
1706 |     <td>Single Frame</td>
1707 |     <td>Control Service</td>
1708 |     <td>Single Frame Info</td>
1709 |     <td>Assigned Session ID</td>
1710 |     <td>
1711 |       Query Binary Header +<br>
1712 |       JSON Data size + <br>
1713 |       Binary Handshake Data size
1714 |     </td>
1715 |     <td>Enumerated number</td>
1716 |   </tr>
1717 |   <tr>
1718 |     <td>0xN</td>
1719 |     <td>0b0</td>
1720 |     <td>0b001</td>
1721 |     <td>0x00</td>
1722 |     <td>0x00</td>
1723 |     <td>0xNN</td>
1724 |     <td>0xC + 0xNNNNNNNN + 0xNNNNNNNN</td>
1725 |     <td>0xNNNNNNNN</td>
1726 |   </tr>
1727 | </table>
1728 | 
1729 | #### 7.2.2 Security Query Binary Header
1730 | 
1731 | The following query header is used by the system and the application to send TLS handshake data.
1732 | 
1733 | <table width="100%">
1734 |   <tr>
1735 |     <th colspan="4">Binary Query Header</th>
1736 |   <tr>
1737 |   <tr>
1738 |     <th>Query Type</th>
1739 |     <th>TLS Message Type</th>
1740 |     <th>Sequential Number</th>
1741 |     <th>JSON Size</th>
1742 |   </tr>
1743 |   <tr>
1744 |     <td>Request</td>
1745 |     <td>Send Handshake Data</td>
1746 |     <td>Any number to be used to correlate query messages</td>
1747 |     <td>Zero</td>
1748 |   </tr>
1749 |   <tr>
1750 |     <td>0x00</td>
1751 |     <td>0x000001</td>
1752 |     <td>0xNNNNNNNN</td>
1753 |     <td>0x00000000</td>
1754 |   </tr>
1755 |   <tr>
1756 |     <th colspan="4">Binary TLS Handshake Data</th>
1757 |   </tr>
1758 | </table>
1759 | 
1760 | ### 7.3 Error handling
1761 | 
1762 | In case of an error, the system and the application should reset the active SSL connection of the current transport connection. This impacts already established secured service sessions as all of them will be closed. The application will need to restart all services which require protection.
1763 | 


--------------------------------------------------------------------------------
/docs/index.md:
--------------------------------------------------------------------------------
  1 | # SmartDeviceLink Protocol
  2 | 
  3 | **Current Version: 4.0.0**
  4 | 
  5 | ## 1. Overview
  6 | The SmartDeviceLink protocol specification describes the method for establishing communication between an application and head unit and registering the application for continued communication with the head unit. The protocol is used as the base formation of packets sent from one module to another. 
  7 | 
  8 | All new SDL implementations should implement the newest version of the protocol.
  9 | 
 10 | ### 1.1 Common Terms
 11 | 
 12 | | Term | Description |
 13 | |------|-------------|
 14 | |**Module / Head Unit**| Hardware implementing the sdl_core software|
 15 | |**Application**| Smart device application that implements the proxy library (iOS or Android)|
 16 | 
 17 | ## 2. Frames
 18 | All transported data is formed with a header followed by an optional payload. The combination of header and payload is referred to as a frame.
 19 | 
 20 | ### 2.1 Version 1 Frame Header
 21 | >Deprecated: Protocol versions 2 and higher. Only used as initial `StartService` packet for establishing communication and version negotiation from application
 22 | 
 23 | 
 24 | <table>
 25 |   <tr>
 26 |     <th colspan="3" width="25%">Byte 1</th>
 27 |     <th width="25%">Byte 2</th>
 28 |     <th width="25%">Byte 3</th>
 29 |     <th width="25%">Byte 4</th>
 30 |   </tr>
 31 |   <tr>
 32 |     <td width="12.5%">Version</td>
 33 |     <td width="3.125%">C</td>
 34 |     <td width="9.375%">Frame Type</td>
 35 |     <td>Service Type</td>
 36 |     <td>Frame Info</td>
 37 |     <td>Session ID</td>
 38 |   </tr>
 39 | </table>
 40 | 
 41 | <table>
 42 |   <tr>
 43 |     <th width="250">Byte 5</th>
 44 |     <th width="25%">Byte 6</th>
 45 |     <th width="25%">Byte 7</th>
 46 |     <th width="25%">Byte 8</th>
 47 |   </tr>
 48 |   <tr>
 49 |     <td colspan="4" align="center">Data Size</td>
 50 |   </tr>
 51 | </table>
 52 | 
 53 | ### 2.2 Version 2 Frame Header
 54 | >Required: Protocol versions 2 and higher
 55 | 
 56 | <table>
 57 |   <tr>
 58 |     <th colspan="3" width="25%">Byte 1</th>
 59 |     <th colspan="1"width="25%">Byte 2</th>
 60 |     <th width="25%">Byte 3</th>
 61 |     <th width="25%">Byte 4</th>
 62 |   </tr>
 63 |   <tr>
 64 |     <td width="12.5%">Version</td>
 65 |     <td width="3.125%">E</td>
 66 |     <td width="9.375%">Frame Type</td>
 67 |     <td>Service Type</td>
 68 |     <td>Frame Info</td>
 69 |     <td>Session ID</td>
 70 |   </tr>
 71 | </table>
 72 | 
 73 | <table >
 74 |   <tr>
 75 |     <th width="300">Byte 5</th>
 76 |     <th width="25%">Byte 6</th>
 77 |     <th width="25%">Byte 7</th>
 78 |     <th width="25%">Byte 8</th>
 79 |   </tr>
 80 |   <tr>
 81 |     <td colspan="4" align="center">Data Size</td>
 82 |   </tr>
 83 | </table>
 84 | 
 85 | <table>
 86 |   <tr>
 87 |     <th width="300">Byte 9</th>
 88 |     <th width="25%">Byte 10</th>
 89 |     <th width="25%">Byte 11</th>
 90 |     <th width="25%">Byte 12</th>
 91 |   </tr>
 92 |   <tr>
 93 |     <td colspan="4" align="center">Message ID</td>
 94 |   </tr>
 95 | </table>
 96 | 
 97 | ### 2.3 Frame Header Fields
 98 | <table width="100%">
 99 |   <tr>
100 |     <th>Field</th>
101 |     <th>Size</th>
102 |     <th width="75%">Description</th>
103 |   </tr>
104 |   <tr>
105 |     <td>Version</td>
106 |     <td>4 bit</td>
107 |     <td>
108 |       <b>Protocol Version</b><br>
109 |       0x1 Protocol version 1 - uses a version 1 Frame Header<br>
110 |       0x2 Protocol version 2 - uses a version 2 Frame Header<br>
111 |       0x3 Protocol version 3 - uses a version 2 Frame Header<br>
112 |       0x4 Protocol version 4 - uses a version 2 Frame Header<br>
113 |       0x5 - 0xF Reserved
114 |     </td>
115 |   </tr>
116 |   <tr>
117 |     <td>C</td>
118 |     <td>1 bit</td>
119 |     <td><b>Compression Flag</b> <br> 0x0 This packet is not compressed <br> 0x1 This packet is compressed <br> <b>Note:</b> Only available in Protocol Version 1</td>
120 |   </tr>
121 |   <tr>
122 |     <td>E</td>
123 |     <td>1 bit</td>
124 |     <td><b>Encryption Flag</b> <br> 0x0 This packet is not encrypted <br> 0x1 This packet is encrypted <br> <b>Note:</b> Only available in Protocol Version 2 and higher</td>
125 |   </tr>
126 |   <tr>
127 |     <td>Frame Type</td>
128 |     <td>3 bit</td>
129 |     <td>
130 |       0x00 Control Frame <br>
131 |       0x01 Single Frame <br>
132 |       0x02 First Frame <br>
133 |       0x03 Consecutive Frame <br>
134 |       0x04 - 0x07 Reserved
135 |     </td>
136 |   </tr>
137 |   <tr>
138 |     <td>Service Type</td>
139 |     <td>8 bit</td>
140 |     <td>
141 |       0x00 Control Service<br>
142 |       0x01 - 0x06 Reserved<br>
143 |       0x07 Remote Procedure Call (RPC) Service<br>
144 |       0x08 - 0x09 Reserved<br>
145 |       0x0A PCM Service<br>
146 |       0x0B Video Service<br>
147 |       0x0C - 0x0E Reserved<br>
148 |       0x0F Bulk Data (Hybrid Service)<br>
149 |       0x10 - 0xFF Reserved
150 |     </td>
151 |   </tr>
152 |   <tr>
153 |     <td>Frame Info</td>
154 |     <td>8 bit</td>
155 |     <td>
156 |       <b>Frame Type = 0x00 (Control Frame)</b><br>
157 |       0x00 Heartbeat<br>
158 |       0x01 Start Service<br>
159 |       0x02 Start Service ACK<br>
160 |       0x03 Start Service NAK<br>
161 |       0x04 End Service<br>
162 |       0x05 End Service ACK<br>
163 |       0x06 End Service NAK<br>
164 |       0x07 - 0xFD Reserved<br>
165 |       0xFE Service Data ACK<br>
166 |       0xFF Heartbeat ACK<br>
167 |       <b>Frame Type = 0x01 (Single Frame)</b><br>
168 |       0x00 - 0xFF Reserved<br>
169 |       <b>Frame Type = 0x02 (First Frame)</b><br>
170 |       0x00 - 0xFF Reserved<br>
171 |       <b>Frame Type = 0x03 (Consecutive Frame)</b><br>
172 |       0x00 Last Frame<br>
173 |       0x01 - 0xFF Frame Number
174 |     </td>
175 |   </tr>
176 |   <tr>
177 |     <td>Session ID</td>
178 |     <td>8 bit</td>
179 |     <td>The session identifier</td>
180 |   </tr>
181 |   <tr>
182 |     <td>Data Size</td>
183 |     <td>32 bit</td>
184 |     <td>
185 |       <b>Frame Type = 0x00 (Control Frame)</b><br>
186 |       0x0 - 0xFFFFFFFF reserved.<br>
187 |       <b>Frame Type = 0x02 (First Frame)</b><br>
188 |       0x08 The data size for a first frame is always 8 bytes. In the payload, the first four bytes denote the Total Size of the data contained in all consecutive frames, and the second four bytes denote the number of consecutive frames following this one<br>
189 |       <b>Frame Type = 0x01 or 0x03 (Single or Consecutive Frame)</b><br>
190 |       The total bytes in this frame's payload
191 |     </td>
192 |   </tr>
193 |   <tr>
194 |     <td>Message ID</td>
195 |     <td>32 bit</td>
196 |     <td>The message identifier, used to uniquely identify this message.<br> 
197 |     <b>Note:</b> Only included in protocol version 2 frame headers and higher</td>
198 |   </tr>
199 | </table>
200 | 
201 | ### 2.4 Max Transport Units
202 | The max transport unit (MTU) of a frame varies based on version. The MTU includes the frame header and payload. The current supported versions and their MTU's respectively are described below.
203 | 
204 | | Version | MTU (bytes) |
205 | |------|-------------|
206 | |**1**| 1500|
207 | |**2**| 1500|
208 | |**3**| 131,084 |
209 | |**4**| 131,084|
210 | 
211 | 
212 | #### 2.4.1 Payload Size
213 | The payload size is determined by the MTU - Frame Header Size. 
214 | 
215 | | Version | Max Payload Size (bytes) |
216 | |------|-------------|
217 | |**1**| 1488|
218 | |**2**| 1488|
219 | |**3**| 131,072 |
220 | |**4**| 131,072|
221 | 
222 | #### 2.4.2 Encrypted MTU
223 | While the supported MTU is the maximum size for that version, if a frame is encrypted it will be subject to the MTU of that encryption protocol as well. That means the MTU will have to be the minimum between SDL's MTU  and the encryption protocol's MTU. 
224 | 
225 | ## 3. Frame Types
226 | ### 3.1 Control Frame 
227 | Control frames are the lowest-level type of packets. They can be sent over any of the defined services. They are used for the control of the services in which they are sent.
228 | 
229 | #### 3.1.1 Special Header Definitions:
230 | | Header Value |Expected values| Description |
231 | |--------------|---------------|-------------|
232 | |Frame Info| `0x00` - `0x06`, `0xFE`, `0xFF`|See below "Frame Info Definitions"|
233 | |Data Size| `0x00`, `0x04`|`0x00` - Majority of control packets do not have payloads<br><br> `0x04` - Used for `StartServiceACK` where the payload is a HashID |
234 | 
235 | 
236 | #### 3.1.2 Frame Info Definitions:
237 | | Frame Info Value| Name | Description |
238 | |------------|------|-------------|
239 | | 0x00| Heartbeat| A ping packet that is sent to ensure the connection is still active and the service is still valid|
240 | | 0x01 | Start Service |Requests that a specific type of service is started |
241 | | 0x02 | Start Service ACK | Acknowledges that the specific service has been started successfully
242 | | 0x03 | Start Service NAK | Negatively acknowledges that the specific service was *not* started
243 | | 0x04 | End Service | Requests that a specific type of service is ended
244 | | 0x05 | End Service ACK | Acknowledges that the specific service has been ended successfully
245 | | 0x06 | End Service NAK |  Negatively acknowledges that the specific service was *not* ended or has not yet been started
246 | | 0xFE | Service Data ACK | *Deprecated*
247 | | 0xFF | Heartbeat ACK | Acknowledges that a Heartbeat control packet has been received
248 | 
249 | ### 3.2 Single Frame
250 | A frame of type Single Frame contains all the data for a particular packet in the payload. The majority of frames sent over the protocol utilize this frame type.
251 | <table width="100%">
252 |   <tr>
253 |   	<th colspan = "2" align="center">Single Frame</th>
254 |   </tr>
255 |   <tr>
256 |     <td width="10%">Header</td>
257 |     <td>Payload</td>
258 |   </tr>
259 |   <tr>
260 |     <td width="20%" style="visibility:hidden;"></td>
261 |     <td align="center">Data</td>
262 |   </tr>
263 | </table>
264 | 
265 | #### 3.2.1 Special Header Definitions:
266 | 
267 | | Header Value |Expected values| Description |
268 | |--------------|---------------|-------------|
269 | |Frame Info| `0x00`|Reserved|
270 | |Data Size| 0x01-0xFFFFFFFF|Total payload size in bytes for this frame|
271 |  
272 | ### 3.3 Multiple Frame Packets
273 | Some payloads will be larger than the maximum transport unit will allow. If that is the case, the payload will be broken up over multiple frames. These frame types are First and Consecutive. 
274 | 
275 | <table width="100%">
276 |   <tr style="visibility:hidden;">
277 |     <td width="5%"></td>
278 |     <td width="5%"></td>
279 |     <td width="5%"></td>
280 |     <td ></td>
281 |     <td width="5%"></td>
282 |     <td></td>
283 |     <td width="5%"></td>
284 |     <td></td>
285 |     <td width="5%"></td>
286 |     <td></td>
287 |     <td></td>
288 |   </tr>
289 |     <tr>
290 |     <td style="visibility:hidden;" colspan="3"></td>
291 |     <td align="center" colspan="100%">Data</td>
292 |   </tr>
293 |   <tr>
294 |   <td style="visibility:hidden;" colspan ="3"></td>
295 |     <td align="center" colspan="2">Data Chunk 1 </td>
296 |     <td align="center" colspan="2">Data Chunk 2 </td>
297 |     <td style="border:0; background-color:white;" align="center" colspan="2">...</td>
298 |     <td align="center" colspan="2">Data Chunk n </td>
299 |   </tr>  
300 |   <tr>
301 |   	<th colspan = "2" align="center">First Frame</th>
302 |   </tr>
303 |   <tr>
304 |     <td> Header</td>
305 |     <td colspan = "1" >Payload</td>
306 |   </tr>
307 |   
308 |   <tr>
309 |      <th colspan = "2" style="visibility:hidden;"></th>
310 |      <th colspan = "3">Consecutive Frame 1</th>
311 |   </tr>
312 |   <tr>
313 |    <td colspan="2" style="visibility:hidden;"></td>
314 | 	<td>Header</td>
315 | 	<td colspan = "2" >Payload</td>  
316 |   </tr>
317 |   <tr>
318 |      <th colspan = "4" style="visibility:hidden;"></th>
319 |      <th colspan = "3">Consecutive Frame 2</th>
320 |   </tr>
321 |   <tr>
322 |    <td colspan="4" style="visibility:hidden;"></td>
323 | 	<td>Header</td>
324 | 	<td colspan = "2" >Payload</td>  
325 |   </tr>
326 |   
327 |   <tr style="border:0;">
328 |      <td colspan = "7" style="visibility:hidden; border:0;"></td>
329 |      <td style="font-size:25px; border:0; background-color:white;" align="center">...</td>
330 |   </tr>
331 |   <tr></tr>
332 |   <tr>
333 |      <th colspan = "8" style="visibility:hidden;"></th>
334 |      <th colspan = "3">Consecutive Frame n</th>
335 |   </tr>
336 |   <tr>
337 |    <td colspan="8" style="visibility:hidden;"></td>
338 | 	<td>Header</td>
339 | 	<td colspan = "2" >Payload</td>  
340 |   </tr>
341 | 
342 | </table> 
343 | 
344 | 
345 | #### 3.3.1 First Frame
346 | The First Frame in a multiple frame payload contains information about the entire sequence of frames so that the receiving end can correctly parse all the frames and reassemble the entire payload. The payload of this frame is only eight bytes and contains information regarding the rest of the sequence.
347 | 
348 | ##### 3.3.1.1 Payload:
349 | <table width = "100%">
350 | 	<tr align="center">
351 | 		<th>Byte</th>
352 | 		<td width = "10%">0</td>
353 | 		<td width = "10%">1</td>
354 | 		<td width = "10%">2</td>
355 | 		<td width = "10%">3</td>
356 | 		<td width = "10%">4</td>
357 | 		<td width = "10%">5</td>
358 | 		<td width = "10%">6</td>
359 | 		<td width = "10%">7</td>
360 | 	</tr>
361 | 	<tr align="center">
362 | 		<td style="visibility:hidden;"></td>
363 | 		<td colspan ="4" >Total size of the original payload being parsed</td>
364 | 		<td colspan ="4" >Number of Consecutive Frames in this sequence</td>
365 | 	</tr>
366 | </table>
367 | 
368 | ##### 3.3.1.2 Special Header Definitions:
369 | 
370 | | Header Value |Expected values| Description |
371 | |--------------|---------------|-------------|
372 | |Frame Info| `0x00`|Reserved|
373 | |Data Size| `0x08`|This frame contains a fixed data size (8 bytes) for the payload.|
374 | 
375 | #### 3.3.2 Consecutive Frame
376 | The Consecutive Frames in a multiple frame payload contain the actual raw data of the original payload. The parsed payload contained in each of the Consecutive Frames' payloads should be buffered until the entire sequence is complete. 
377 | 
378 | ##### 3.3.2.1 Special Header Definitions:
379 | 
380 | | Header Value |Expected values| Description |
381 | |--------------|---------------|-------------|
382 | |Frame Info| `0x00` - `0xFF`|Values `0x01` - `0xFF` are used incrementally as each consecutive frame is created and sent in the sequence. eg The first consecutive packet in the sequence will have the value `0x01`, the next consecutive frame that contains the next chunk of data in the sequence will have the value `0x02`. <br><br>If the sequence reaches `0xFF` with more frames to create, it shall rollover to `0x01` **not** `0x00` as it is reserved. <br><br>`0x00` is only used for the last consecutive frame in a multi-frame sequence and the last frame must have this value.|
383 | |Data Size| `0x01` - `0xFFFFFFFF`|Payload size in bytes for only this frame |
384 | 
385 | ## 4. Establishing Communication
386 | 
387 | ### 4.1 Transport Layer
388 | >Required: All Protocol Versions
389 | 
390 | A physical transport must be established between a head unit and an application before an SDL session can start. 
391 | 
392 | ### 4.2 Version Negotiation
393 | >Required: All Protocol Versions
394 | 
395 | Once a transport is established, each application must negotiate the maximum supported protocol version with the head unit. To establish basic communication and register with the head unit, the application must start an RPC service (Service Type: 0x07), using a *Version 1 Protocol Header*.
396 | 
397 | ##### Application -> Head Unit
398 | <table width="100%">
399 |   <tr>
400 |     <th>Version</th>
401 |     <th>C</th>
402 |     <th>Frame Type</th>
403 |     <th>Service Type</th>
404 |     <th>Frame Info</th>
405 |     <th>Session Id</th>
406 |     <th>Data Size</th>
407 |   </tr>
408 |   <tr>
409 |     <td>1</td>
410 |     <td>no</td>
411 |     <td>Control</td>
412 |     <td>RPC</td>
413 |     <td>Start Service</td>
414 |     <td>0</td>
415 |     <td>0</td>
416 |   </tr>
417 |   <tr>
418 |     <td>0b0001</td>
419 |     <td>0b0</td>
420 |     <td>0b000</td>
421 |     <td>0x07</td>
422 |     <td>0x01</td>
423 |     <td>0x00</td>
424 |     <td>0x00000000</td>
425 |   </tr>
426 | </table>
427 | 
428 | #### 4.2.1 Success
429 | 
430 | If the head unit allows the RPC service to start, it will respond with a `StartServiceACK` containing its maximum supported protocol version. The packet structure will also match that of the supplied version; if the module's maximum supported version is 1, the packet will contain an 8 byte header (version 1), otherwise it will contain a 12 byte header (version 2). The application will then find the highest version supported by both the module and the application. This will be the determined version used for this session and will be used for all other packets sent from this point forward.
431 | 
432 | The payload of the `StartServiceACK` will contain a hash of the service which was started on the head unit if the payload size is greater than 0. This hash should be stored by an application and is needed in the end communication flow.
433 | 
434 | ##### Head Unit -> Application
435 | <table width="100%">
436 |   <tr>
437 |     <th>Version</th>
438 |     <th>E</th>
439 |     <th>Frame Type</th>
440 |     <th>Service Type</th>
441 |     <th>Frame Info</th>
442 |     <th>Session Id</th>
443 |     <th>Data Size</th>
444 |     <th>Message ID</th>
445 |   </tr>
446 |   <tr>
447 |     <td>Max Module Version (4)</td>
448 |     <td>no</td>
449 |     <td>Control</td>
450 |     <td>RPC</td>
451 |     <td>Start Service ACK</td>
452 |     <td>Assigned Session</td>
453 |     <td>4</td>
454 |     <td>2</td>
455 |   </tr>
456 |   <tr>
457 |     <td>0b0100</td>
458 |     <td>0b0</td>
459 |     <td>0b000</td>
460 |     <td>0x07</td>
461 |     <td>0x02</td>
462 |     <td>0x01</td>
463 |     <td>0x00000004</td>
464 |     <td>0x0000000n</td>
465 |   </tr>
466 | </table>
467 | 
468 | #### 4.2.2 Failure
469 | If a session has already been started, or can't be started, a `StartServiceNAK` will be sent in response to the `StartService` packet.
470 | 
471 | ##### Head Unit -> Application
472 | <table width="100%">
473 |   <tr>
474 |     <th>Version</th>
475 |     <th>E</th>
476 |     <th>Frame Type</th>
477 |     <th>Service Type</th>
478 |     <th>Frame Info</th>
479 |     <th>Session Id</th>
480 |     <th>Data Size</th>
481 |     <th>Message ID</th>
482 |   </tr>
483 |   <tr>
484 |     <td>Max Module Version (4)</td>
485 |     <td>no</td>
486 |     <td>Control</td>
487 |     <td>RPC</td>
488 |     <td>Start Service NAK</td>
489 |     <td>0</td>
490 |     <td>0</td>
491 |     <td>0</td>
492 |   </tr>
493 |   <tr>
494 |     <td>0b0100</td>
495 |     <td>0b0</td>
496 |     <td>0b000</td>
497 |     <td>0x07</td>
498 |     <td>0x03</td>
499 |     <td>0x00</td>
500 |     <td>0x00000000</td>
501 |     <td>0x00000000</td>
502 |   </tr>
503 | </table>
504 | 
505 | ### 4.3 Registration
506 | >Required: All Protocol Versions
507 | 
508 | Each application registers for continued communication with the head unit by sending a `RegisterAppInterface` Request RPC to the head unit via the RPC Service. Additional services can only be started after a successful `RegisterAppInterface` Response RPC has been sent from the head unit to the application.
509 | 
510 | ### 4.4 Starting other services
511 | While the RPC service is the default service that is started to establish a connection and a session, the application may wish to start other services. Similar to the process in Section 4, all services that are to be to started in a session require a `StartService` packet to be sent from the application. If the module supports and allows that service type to be started, it will respond with a `StartServiceACK` that has a payload of the hash ID for that service. If the module is unable to start that service or that application does not have access to that service, it will respond with a `StartServiceNAK`. 
512 | 
513 | ### 4.5 Heartbeat
514 | >**Deprecated: Protocol Versions 4 and higher** <br>
515 | >Required: Protocol Version 3<br>
516 | >Added: Protocol Version 3
517 | 
518 | After a successful start service exchange between the application and head unit both the application and head unit are required to be able to respond to heartbeat messages if the negotiated protocol version is 3. After sending a heartbeat, if the application or head unit does not respond within a timeout (custom per app/head unit), the sender will disconnect. The sender's timer for the heartbeat timeout should be reset every time any message is received. Heartbeats are sent using the Control Service Type (0x00)
519 | 
520 | #### 4.5.1 Heartbeat Request
521 | 
522 | >Note: The request can originate from either the Head Unit or the Application
523 | 
524 | ##### Head Unit -> Application
525 | <table width="100%">
526 |   <tr>
527 |     <th>Version</th>
528 |     <th>E</th>
529 |     <th>Frame Type</th>
530 |     <th>Service Type</th>
531 |     <th>Frame Info</th>
532 |     <th>Session Id</th>
533 |     <th>Data Size</th>
534 |     <th>Message ID</th>
535 |   </tr>
536 |   <tr>
537 |     <td>4</td>
538 |     <td>no</td>
539 |     <td>Control</td>
540 |     <td>Control</td>
541 |     <td>Heartbeat</td>
542 |     <td>0</td>
543 |     <td>0</td>
544 |     <td>0</td>
545 |   </tr>
546 |   <tr>
547 |     <td>0b0100</td>
548 |     <td>0b0</td>
549 |     <td>0b000</td>
550 |     <td>0x00</td>
551 |     <td>0x00</td>
552 |     <td>0x00</td>
553 |     <td>0x00000000</td>
554 |     <td>0x00000000</td>
555 |   </tr>
556 | </table>
557 | 
558 | #### 4.5.2 Heartbeat ACK
559 | 
560 | >Note: The response ACK will originate from the Head Unit or the Application based on the origin of the request
561 | 
562 | ##### Application -> Head Unit
563 | <table width="100%">
564 |   <tr>
565 |     <th>Version</th>
566 |     <th>E</th>
567 |     <th>Frame Type</th>
568 |     <th>Service Type</th>
569 |     <th>Frame Info</th>
570 |     <th>Session Id</th>
571 |     <th>Data Size</th>
572 |     <th>Message ID</th>
573 |   </tr>
574 |   <tr>
575 |     <td>4</td>
576 |     <td>no</td>
577 |     <td>Control</td>
578 |     <td>Control</td>
579 |     <td>Heartbeat ACK</td>
580 |     <td>0</td>
581 |     <td>0</td>
582 |     <td>0</td>
583 |   </tr>
584 |   <tr>
585 |     <td>0b0100</td>
586 |     <td>0b0</td>
587 |     <td>0b000</td>
588 |     <td>0x00</td>
589 |     <td>0xFF</td>
590 |     <td>0x00</td>
591 |     <td>0x00000000</td>
592 |     <td>0x00000000</td>
593 |   </tr>
594 | </table>
595 | 
596 | #### 4.5.3 Heartbeat NAK
597 | There is currently no heartbeat NAK.
598 | 
599 | ## 5. Services
600 | Every active session has the ability to start any of the services defined in this protocol spec as long as they have permission on the module in which they are connected. Every session can only have one of each type of service open at a time. 
601 |  
602 | Messages sent have a priority based on their Service Type. Lower values for service type have higher delivery priority. A message's payload's format is based on the different service types defined below.
603 | 
604 | ### 5.1 Control Service
605 | >Required: All Protocol Versions
606 | 
607 | The control service is the lowest level service available. While Control Frame packets are used frequently, the control service itself is rarely used.   
608 | 
609 | ### 5.2 RPC Service
610 | >Required: All Protocol Versions
611 | 
612 | The RPC service is used to send requests, responses, and notifications between an application and a head unit. Valid messages are defined in the [RPC Specification](https://github.com/smartdevicelink/sdl_core/blob/master/src/components/interfaces/MOBILE_API.xml).
613 | 
614 | The payload of a message sent via the RPC service, which directly follows the Frame Header in the packet, consists of a Binary Header, and JSON data representing the RPC.
615 | 
616 | ##### RPC Payload
617 | 
618 | <table>
619 |   <tr>
620 |     <td align="center" width="5000">Binary Header</td>
621 |   </tr>
622 |   <tr>
623 |     <td align="center">JSON Data</td>
624 |   </tr>
625 | </table>
626 | 
627 | #### 5.2.1 Binary Header
628 | >Required: Protocol Version 2 and greater
629 | 
630 | <table>
631 |   <tr>
632 |     <th colspan="2" width="25%">Byte 1</th>
633 |     <th width="25%">Byte 2</th>
634 |     <th width="25%">Byte 3</th>
635 |     <th width="25%">Byte 4</th>
636 |   </tr>
637 |   <tr>
638 |     <td width="12.5%">RPC Type</td>
639 |     <td colspan="4" align="center">RPC Function ID</td>
640 |   </tr>
641 |   <tr>
642 |     <td colspan="5" align="center">Correlation ID</td>
643 |   </tr>
644 |   <tr>
645 |     <td colspan="5" align="center">JSON Size</td>
646 |   </tr>
647 | </table>
648 | 
649 | ##### 5.2.1.1 Binary Header Fields
650 | <table>
651 |   <tr>
652 |     <th>Field</th>
653 |     <th>Size</th>
654 |     <th>Description</th>
655 |   </tr>
656 |   <tr>
657 |     <td>RPC Type</td>
658 |     <td>4 bit</td>
659 |     <td>
660 |       0x0 Request<br>
661 |       0x1 Response<br>
662 |       0x2 Notification<br>
663 |       0x3 - 0xF Reserved
664 |     </td>
665 |   </tr>
666 |   <tr>
667 |     <td>RPC Function ID</td>
668 |     <td>28 bit</td>
669 |     <td>The Function ID of each RPC is specific to each version of the <a href="https://github.com/smartdevicelink/sdl_core/blob/develop/src/components/interfaces/MOBILE_API.xml#L2146-2207">RPC Specification</a> but in general do not change from version to version.
670 |   </tr>
671 |   <tr>
672 |     <td>Correlation ID</td>
673 |     <td>32 bits</td>
674 |     <td>The Correlation ID is used to map a request to its response. In Protocol Version 1, when the Binary Header did not exist, the Correlation ID was included as part of the JSON and has a max value of 65536</td>
675 |   </tr>
676 |   <tr>
677 |     <td>JSON Size</td>
678 |     <td>32 bits</td>
679 |     <td>The size of the JSON Data following the Binary Header in the RPC Payload</td>
680 |   </tr>
681 | </table>
682 | 
683 | ### 5.3 Hybrid (Bulk Data) Service
684 | >Required: Protocol Version 2 and greater
685 | 
686 | The Hybrid Service does not need to be explicitly started; all applications that have successfully started the RPC Service have access to the Hybrid Service.
687 | 
688 | The Hybrid Service is similar to the RPC Service but adds a bulk data field. The payload of a message sent via the Hybrid service consists of a Binary Header, JSON Data, and Bulk Data.
689 | 
690 | The size of the Bulk Data field is the Data Size (Found in the Frame Header) minus the 12 Bytes of the Binary Header minus the JSON Size (Found in the Binary Header).
691 | 
692 | The Binary Header of a message using the Hybrid Service is the same as the Binary Header of a message using the RPC Service.
693 | 
694 | ##### Hybrid Service Payload
695 | 
696 | <table>
697 |   <tr>
698 |     <td align="center" width="5000">Binary Header</td>
699 |   </tr>
700 |   <tr>
701 |     <td align="center">JSON Data</td>
702 |   </tr>
703 |   <tr>
704 |     <td align="center">Bulk Data</td>
705 |   </tr>
706 | </table>
707 | 
708 | ### 5.4 Audio Service (PCM)
709 | >Available: Protocol Version 3 and greater
710 | 
711 | The application can start the audio service to send PCM audio data to the head unit. After the `StartService` packet is sent and the ACK received, the payload for the Audio Service is only PCM audio data.
712 | 
713 | ### 5.5 Video Service (H.264)
714 | >Available: Protocol Version 3 and greater
715 | 
716 | The application can start the video service to send H.264 video data to the head unit. After the `StartService` packet is sent and the ACK received, the payload for the Video Service is only H.264 video data.
717 | 
718 | 
719 | ## 6. Ending Communication
720 | The application may request it's session to be ended outside of a transport disconnect, module power cycle, etc. 
721 | ### 6.1 Completely Closing  a Session and Ending All Services
722 | To close out a communication session with the head unit, an application sends an `EndService` packet with service type 7 (RPC) to the module. The `EndService` packet payload should include the correct hash ID supplied with the `StartServiceACK`. 
723 | 
724 | ### 6.2 Closing Specific Services
725 | If the application doesn't want to completely stop its session, but only wishes to close a specific session it can do so using an `EndService` packet that's service type matches the service that the application is trying to close. The `EndService` packet should include the hash ID in its payload that was contained in the `StartServiceACK` for  that specific service.
726 | 


--------------------------------------------------------------------------------