smartdevicelink/protocol_spec

Describes the communication protocol between a smartdevicelink enabled head unit and mobile application

SmartDeviceLink Protocol

Current Version: 5.4.1

1. Overview

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.

All new SDL implementations should implement the newest version of the protocol.

1.1 Common Terms

Term	Description
Module / Head Unit	Hardware implementing the sdl_core software
Application	Smart device application that implements the proxy library (iOS or Android)

2. Frames

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.

2.1 Version 1 Frame Header

Deprecated: Protocol versions 2 and higher. Only used as initial StartService packet for establishing communication and version negotiation from application

Byte 1			Byte 2	Byte 3	Byte 4
Version	C	Frame Type	Service Type	Frame Info	Session ID

Byte 5	Byte 6	Byte 7	Byte 8
Data Size

2.2 Version 2 Frame Header

Required: Protocol versions 2 and higher

Byte 1			Byte 2	Byte 3	Byte 4
Version	E	Frame Type	Service Type	Frame Info	Session ID

Byte 5	Byte 6	Byte 7	Byte 8
Data Size

Byte 9	Byte 10	Byte 11	Byte 12
Message ID

2.3 Frame Header Fields

Field	Size	Description
Version	4 bit	Protocol Version 0x1 Protocol version 1 - uses a version 1 Frame Header 0x2 Protocol version 2 - uses a version 2 Frame Header 0x3 Protocol version 3 - uses a version 2 Frame Header 0x4 Protocol version 4 - uses a version 2 Frame Header 0x5 Protocol version 5 - uses a version 2 Frame Header 0x6 - 0xF Reserved
C	1 bit	Compression Flag 0x0 This packet is not compressed 0x1 This packet is compressed Note: Only available in Protocol Version 1
E	1 bit	Encryption Flag 0x0 This packet is not encrypted 0x1 This packet is encrypted Note: Only available in Protocol Version 2 and higher. Must be always set to zero for a First Frame
Frame Type	3 bit	0x00 Control Frame 0x01 Single Frame 0x02 First Frame 0x03 Consecutive Frame 0x04 - 0x07 Reserved
Service Type	8 bit	0x00 Control Service 0x01 - 0x06 Reserved 0x07 Remote Procedure Call (RPC) Service 0x08 - 0x09 Reserved 0x0A Audio Service 0x0B Video Service 0x0C - 0x0E Reserved 0x0F Bulk Data (Hybrid Service) 0x10 - 0xFF Reserved
Frame Info	8 bit	Frame Type = 0x00 (Control Frame) 0x00 Heartbeat 0x01 Start Service 0x02 Start Service ACK 0x03 Start Service NAK 0x04 End Service 0x05 End Service ACK 0x06 End Service NAK 0x07 Register Secondary Transport 0x08 Register Secondary Transport ACK 0x09 Register Secondary Transport NAK 0x0A - 0xFC Reserved 0xFD Transport Event Update 0xFE Service Data ACK 0xFF Heartbeat ACK Frame Type = 0x01 (Single Frame) 0x00 - 0xFF Reserved Frame Type = 0x02 (First Frame) 0x00 - 0xFF Reserved Frame Type = 0x03 (Consecutive Frame) 0x00 Last Frame 0x01 - 0xFF Frame Number
Session ID	8 bit	The session identifier
Data Size	32 bit	Frame Type = 0x00 (Control Frame) 0x0 - 0xFFFFFFFF reserved. Frame Type = 0x02 (First Frame) 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 Frame Type = 0x01 or 0x03 (Single or Consecutive Frame) 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.
Message ID	32 bit	The message identifier, used to uniquely identify this message. Note: Only included in protocol version 2 frame headers and higher

2.4 Max Transport Units

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.

Version	MTU (bytes)
1	1500
2	1500
3	131,084
4	131,084
5	131,084 default or negotiated (See Control Frame Payloads)

2.4.1 Payload Size

The payload size is determined by the MTU - Frame Header Size.

Version	Max Payload Size (bytes)
1	1488
2	1488
3	131,072
4	131,072
5	131,072 default or (Negotiated MTU - 12 bytes) (See Control Frame Payloads)

2.4.2 Encrypted MTU

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.

3. Frame Types

3.1 Control Frame

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.

3.1.1 Special Header Definitions:

Header Value	Expected values	Description
Frame Info	0x00 - 0x06, 0xFE, 0xFF	See below "Frame Info Definitions"
Data Size	0x00, 0x04	0x00 - Majority of control packets do not have payloads 0x04 - Used for StartServiceACK where the payload is a HashID

3.1.2 Frame Info Definitions:

Frame Info Value	Name	Description
0x00	Heartbeat	A ping packet that is sent to ensure the connection is still active and the service is still valid
0x01	Start Service	Requests that a specific type of service is started
0x02	Start Service ACK	Acknowledges that the specific service has been started successfully
0x03	Start Service NAK	Negatively acknowledges that the specific service was not started
0x04	End Service	Requests that a specific type of service is ended
0x05	End Service ACK	Acknowledges that the specific service has been ended successfully
0x06	End Service NAK	Negatively acknowledges that the specific service was not ended or has not yet been started
0x07	Register Secondary Transport	Request for a session registered on a primary transport to use a secondary transport. This frame should only be sent on the Secondary Transport that the session is requesting.
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. This frame must be sent on the Secondary Transport in which the original request was sent.
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. This frame must be sent on the Secondary Transport in which the original request was sent.
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.
0xFE	Service Data ACK	Deprecated
0xFF	Heartbeat ACK	Acknowledges that a Heartbeat control packet has been received

3.1.3 Payloads

Added: Protocol Version 5
Note: All parameters are optional

Control frames use BSON 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.

If there is no data to send for a given parameter, the parameter should not be included.

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.

3.1.3.1 Control Service

3.1.3.1.1 Register Secondary Transport

No parameters

3.1.3.1.2 Register Secondary Transport ACK

No parameters

3.1.3.1.3 Register Secondary Transport NAK

Tag Name	Type	Introduced	Description
reason	String	5.1.0	A string describing the reason of failure

3.1.3.1.4 Transport Event Update

Tag Name	Type	Introduced	Description
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"). An empty string indicates that the TCP transport becomes unavailable.
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.

3.1.3.2 RPC Service

3.1.3.2.1 Start Service

Note: While this includes a payload, it will remain a v1 frame header to ensure backwards compatibility with older systems.

Tag Name	Type	Introduced	Description
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"

3.1.3.2.2 Start Service ACK

Tag Name	Type	Introduced	Description
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.
hashId	int32	5.0.0	Hash ID to identify this session and used when sending an EndService control frame for the RPC service type
mtu	int64	5.0.0	Max transport unit to be used for this service
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. 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. If there are no currently available Secondary Transports or the functionality is not supported, this parameter should be omitted or be an empty array.
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. If this parameter is not included the Primary Transport should be used for the audio service.
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. If this parameter is not included the Primary Transport should be used for the video service.
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.
make	String	5.4.0	Vehicle make value. Used by OEM exclusive apps to identify whether current vehicle is supported or not.
model	String	5.4.0	Vehicle model value. Used by OEM exclusive apps to identify whether current vehicle is supported or not.
modelYear	String	5.4.0	Vehicle model year value. Used by OEM exclusive apps to identify whether current vehicle is supported or not.
trim	String	5.4.0	Vehicle trim value. Used by OEM exclusive apps to identify whether current vehicle is supported or not.
systemSoftwareVersion	String	5.4.0	Vehicle system software version value. Can be specified in any format desired by the OEM.
systemHardwareVersion	String	5.4.0	Vehicle system hardware version value. Can be specified in any format desired by the OEM.

list of transport type strings

String	Description
IAP_BLUETOOTH	iAP over Bluetooth
IAP_USB	iAP over USB where it is not possible to distinguish between host or device mode
IAP_USB_HOST_MODE	iAP over USB, and the phone is running as host
IAP_USB_DEVICE_MODE	iAP over USB, and the phone is running as device
IAP_CARPLAY	iAP over Carplay wireless
SPP_BLUETOOTH	Bluetooth SPP.
AOA_USB	Android Open Accessory
TCP_WIFI	TCP connection over Wi-Fi

3.1.3.2.3 Start Service NAK

Tag Name	Type	Introduced	Description
rejectedParams	String Array	5.0.0	An array of rejected parameters
reason	String	5.3.0	A string describing the reason of failure

3.1.3.2.4 End Service

Tag Name	Type	Introduced	Description
hashId	int32	5.0.0	Hash ID supplied in the StartServiceACK for this service type

3.1.3.2.5 End Service ACK

3.1.3.2.6 End Service NAK

Tag Name	Type	Introduced	Description
rejectedParams	String Array	5.0.0	An array of rejected parameters such as: [hashId]
reason	String	5.3.0	A string describing the reason of failure

3.1.3.3 Audio Service

3.1.3.3.1 Start Service

No parameters

3.1.3.3.2 Start Service ACK

Tag Name	Type	Introduced	Description
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.

3.1.3.3.3 Start Service NAK

Tag Name	Type	Introduced	Description
rejectedParams	String Array	5.0.0	An array of rejected parameters such as: [videoProtocol, videoCodec]
reason	String	5.3.0	A string describing the reason of failure

3.1.3.3.4 End Service

No parameters

3.1.3.3.5 End Service ACK

No parameters

3.1.3.3.6 End Service NAK

Tag Name	Type	Introduced	Description
rejectedParams	String Array	5.0.0	An array of rejected parameters such as: [hashId]
reason	String	5.3.0	A string describing the reason of failure

3.1.3.4 Video Service

3.1.3.4.1 Start Service

Tag Name	Type	Introduced	Description
height	int32	5.0.0	Desired height from the client requesting the video service to start
width	int32	5.0.0	Desired width from the client requesting the video service to start
videoProtocol	String	5.0.0	Desired video protocol to be used. See VideoStreamingProtocol RPC
videoCodec	String	5.0.0	Desired video codec to be used. See VideoStreamingCodec RPC

3.1.3.4.2 Start Service ACK

Tag Name	Type	Introduced	Description
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.
height	int32	5.0.0	Accepted height from the client requesting the video service to start
width	int32	5.0.0	Accepted width from the client requesting the video service to start
videoProtocol	String	5.0.0	Accepted video protocol to be used. See VideoStreamingProtocol RPC
videoCodec	String	5.0.0	Accepted video codec to be used. See VideoStreamingCodec RPC

3.1.3.4.3 Start Service NAK

Tag Name	Type	Introduced	Description
rejectedParams	String Array	5.0.0	An array of rejected parameters such as: [videoProtocol, videoCodec]
reason	String	5.3.0	A string describing the reason of failure

3.1.3.4.4 End Service

No parameters

3.1.3.4.5 End Service ACK

No parameters

3.1.3.4.6 End Service NAK

Tag Name	Type	Introduced	Description
rejectedParams	String Array	5.0.0	An array of rejected parameters such as: [hashId]
reason	String	5.3.0	A string describing the reason of failure

3.2 Single Frame

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.

Single Frame
Header	Payload
	Data

3.2.1 Special Header Definitions:

Header Value	Expected values	Description
Frame Info	0x00	Reserved
Data Size	0x01-0xFFFFFFFF	Total payload size in bytes for this frame

3.3 Multiple Frame Packets

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.

			Data
			Data Chunk 1		Data Chunk 2		...		Data Chunk n
First Frame
Header	Payload
		Consecutive Frame 1
		Header	Payload
				Consecutive Frame 2
				Header	Payload
							...
								Consecutive Frame n
								Header	Payload

3.3.1 First Frame

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.

3.3.1.1 Payload:

Byte	0	1	2	3	4	5	6	7
	Total size of the original payload being parsed				Number of Consecutive Frames in this sequence

3.3.1.2 Special Header Definitions:

Header Value	Expected values	Description
Frame Info	0x00	Reserved
Data Size	0x08	This frame contains a fixed data size (8 bytes) for the payload.

3.3.2 Consecutive Frame

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.

3.3.2.1 Special Header Definitions:

Header Value	Expected values	Description
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. If the sequence reaches 0xFF with more frames to create, it shall rollover to 0x01 not 0x00 as it is reserved. 0x00 is only used for the last consecutive frame in a multi-frame sequence and the last frame must have this value.
Data Size	0x01 - 0xFFFFFFFF	Payload size in bytes for only this frame

4. Establishing Communication

4.1 Transport Layer

Required: All Protocol Versions

A physical transport must be established between a head unit and an application before an SDL session can start.

4.2 Version Negotiation

Required: All Protocol Versions

4.2.1 Overview

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.

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.

4.2.1.1 Version 1-4 Negotiation

Required for Protocol Versions 1 through 4

Proxy	Direction	Core
StartService Version: v1 Payload: no payload	----------->
	<-----------	StartServiceACK Version: Max supported by Core Payload: raw bytes for hashID
SingleFrame (or other RPC supporting Frame Type) Version: Highest version supported by both Core and Proxy Payload: Lots of bytes	----------->	Sets negotiated version.

4.2.1.2 Version 5+ Negotiation

Required for Protocol Versions 5 and newer

Proxy	Direction	Core
StartService Version: v1 Payload: Constructed payload [protocolVersion: 5.x.x]	----------->	v4 Core: Ignores payload, sends protocol version 4 frame and uses previous negotiation scheme. v5+ Core: Reads in payload data, uses this information to determine version.
	<-----------	StartServiceACK Version: Highest version supported by both Core and Proxy Payload: Constructed payload [protocolVersion: 5.x.x, hashId: 0x9873, mtu: 130687]
SingleFrame Version: Highest version supported by both Core and Proxy Payload: Lots of bytes	----------->

4.2.2 Starting Communication

The application sends a StartService frame to the module containing no payload.

Application -> Head Unit

4.2.2.1 Versions 1 - 4

Version	C	Frame Type	Service Type	Frame Info	Session Id	Data Size
1	no	Control	RPC	Start Service	0	0
0b0001	0b0	0b000	0x07	0x01	0x00	0x00000000

4.2.2.2 Versions 5 and newer

Note: Even though this is a Protocol Version 1 frame header it includes a payload. This is a very special exception.

Payload includes a constructed BSON object that has a single parameter of protocolVersion that describes the applications max supported Protocol Version.

Version	C	Frame Type	Service Type	Frame Info	Session Id	Data Size
1	no	Control	RPC	Start Service	0	Size of Payload
0b0001	0b0	0b000	0x07	0x01	0x00	0xNNNNNNNN

Payload
[protocolVersion: x.x.x]

4.2.3 Success

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.

Head Unit -> Application

4.2.3.1 Protocol Versions 1-4

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.

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.

Version	E	Frame Type	Service Type	Frame Info	Session Id	Data Size	Message ID
Max Module Version (4)	no	Control	RPC	Start Service ACK	Assigned Session	4	2
0b0100	0b0	0b000	0x07	0x02	0x01	0x00000004	0x0000000n

4.2.3.2 Protocol Versions 5 and newer

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.

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.

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.

4.2.3.2.1 Protocol Version Supplied in StartService

Version	E	Frame Type	Service Type	Frame Info	Session Id	Data Size	Message ID
Max major version supported by module and application	no	Control	RPC	Start Service ACK	Assigned Session	Size of payload	2
0bNNNN	0b0	0b000	0x07	0x02	0x01	0xNNNNNNNN	0x0000000n

Payload
[protocolVersion: x.x.x, hashId: 0xNNNN, mtu: 130687]

4.2.3.2.2 Protocol Version Not Supplied in StartService

Version	E	Frame Type	Service Type	Frame Info	Session Id	Data Size	Message ID
Max version application can possibly support (4)	no	Control	RPC	Start Service ACK	Assigned Session	4	2
0b0100	0b0	0b000	0x07	0x02	0x01	0x00000004	0x0000000n

4.2.4 Failure

If a session has already been started, or can't be started, a StartServiceNAK will be sent in response to the StartService packet.

Head Unit -> Application

4.2.4.1 Protocol Versions 1 through 4

Version	E	Frame Type	Service Type	Frame Info	Session Id	Data Size	Message ID
Max Module Version (4)	no	Control	RPC	Start Service NAK	0	0	0
0b0100	0b0	0b000	0x07	0x03	0x00	0x00000000	0x00000000

4.2.4.1 Protocol Versions 5 and Newer

Version	E	Frame Type	Service Type	Frame Info	Session Id	Data Size	Message ID
Max Module Version (4)	no	Control	RPC	Start Service NAK	0	Size of Payload	0
0b0100	0b0	0b000	0x07	0x03	0x00	0xNNNNNNNN	0x00000000

Payload
[rejectedParams:[protocolVersion, x, x]]

4.2.5 Start Service

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.

4.3 Registration

Required: All Protocol Versions

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.

4.4 Starting other services

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.

4.5 Heartbeat

Deprecated: Protocol Versions 4 and higher
Required: Protocol Version 3
Added: Protocol Version 3

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)

4.5.1 Heartbeat Request

Note: The request can originate from either the Head Unit or the Application

Head Unit -> Application

Version	E	Frame Type	Service Type	Frame Info	Session Id	Data Size	Message ID
4	no	Control	Control	Heartbeat	0	0	0
0b0100	0b0	0b000	0x00	0x00	0x00	0x00000000	0x00000000

4.5.2 Heartbeat ACK

Note: The response ACK will originate from the Head Unit or the Application based on the origin of the request

Application -> Head Unit

Version	E	Frame Type	Service Type	Frame Info	Session Id	Data Size	Message ID
4	no	Control	Control	Heartbeat ACK	0	0	0
0b0100	0b0	0b000	0x00	0xFF	0x00	0x00000000	0x00000000

4.5.3 Heartbeat NAK

There is currently no heartbeat NAK.

4.6 Secondary Transport

Added: Protocol version 5.1.0

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".

4.6.1 Secondary Transport Registration

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.

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 aRegisterSecondaryTransportACK or RegisterSecondaryTransportNAK frame. If the registration was successful and the application receives a RegisterSecondaryTransportACK, it may then utilize the Secondary Transport to start services.

4.6.1.1 RegisterSecondaryTransport

Application -> Head Unit

Version	E	Frame Type	Service Type	Frame Info	Session Id	Data Size	Message ID
Max major version supported by module and application	no	Control	Control	Register Secondary Transport	Session Id assigned on Primary Transport	0	1
0bNNNN	0b0	0b000	0x00	0x07	0xNN	0x00000000	0x00000001

4.6.1.2 RegisterSecondaryTransportACK

Head Unit -> Application

Version	E	Frame Type	Service Type	Frame Info	Session Id	Data Size	Message ID
Max major version supported by module and application	no	Control	Control	Register Secondary Transport ACK	Session Id assigned on Primary Transport	0	2
0bNNNN	0b0	0b000	0x00	0x08	0xNN	0x00000000	0x00000002

4.6.1.3 RegisterSecondaryTransportNAK

Head Unit -> Application

Version	E	Frame Type	Service Type	Frame Info	Session Id	Data Size	Message ID
Max major version supported by module and application if known, otherwise 5	no	Control	Control	Register Secondary Transport NAK	Session Id assigned on Primary Transport	0	2
0bNNNN	0b0	0b000	0x00	0x09	0xNN	0x00000000	0x00000002

4.6.2 Transport Event Update

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.

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.

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.

4.6.2.1 TransportEventUpdate

Head Unit -> Application

Version	E	Frame Type	Service Type	Frame Info	Session Id	Data Size	Message ID
Max major version supported by module and application	no	Control	Control	Transport Event Update	Session Id assigned on Primary Transport	Size of payload	Variable
0bNNNN	0b0	0b000	0x00	0xFD	0xNN	0xNNNNNNNN	0xNNNNNNNN

Payload
[tcpIpAddress:"x.x.x.x", tcpPort:NNNN]

4.6.3 Starting Services on Secondary Transports

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)

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.

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.

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.

4.6.4 Terminating Secondary Transport

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.

5. Services

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.

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.

5.1 Control Service

Required: All Protocol Versions

The control service is the lowest level service available. While Control Frame packets are used frequently, the control service itself is rarely used.

5.1.1 Security Query

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.

5.1.1.1 Payload

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.

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.

Binary Query Header

JSON Data

Binary Data

5.1.1.2 Binary Header

Byte 1	Byte 2	Byte 3	Byte 4
Query Type	Query ID
Sequential Number
JSON Size

5.1.1.2.1 Binary Header Fields

Field	Size	Description
Query Type	8 bit	0x00 Request 0x01 - 0x0F Reserved 0x10 Response 0x11 - 0x1F Reserved 0x20 Notification 0x21 - 0xFE Reserved 0xFF Invalid Query Type
Query ID	24 bit	0x000001 Send Handshake Data 0x000002 Send Internal Error 0x000003 - 0xFFFFFE Reserved 0xFFFFFF Invalid Query ID
Sequential Number	32 bit	Message ID can be set by the mobile libraries to track security messages. The system uses the same Message ID when replying to the query allowing the mobile libraries to correlate messages.
JSON Size	32 bit	The size of the JSON data following the binary query header. Any additional data following the JSON data in the payload is binary data.

5.1.1.3 Send Handshake Data

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.

5.1.1.3.1 Request Payload

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.

Binary Query Header
Query Type	TLS Message Type	Sequential Number	JSON Size
Request	Send Handshake Data	Any number to be used to correlate query messages	Zero
0x00	0x000001	0xNNNNNNNN	0x00000000
Binary Data: SSL Handshake Request

5.1.1.3.2 Response Payload

Binary Query Header
Query Type	TLS Message Type	Sequential Number	JSON Size
Response	Send Handshake Data	Any number to be used to correlate query messages	Zero
0x10	0x000001	0xNNNNNNNN	0x00000000
Binary Data: SSL Handshake Response

5.1.1.4 Send Internal Error

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.

The error code in JSON data and the binary data are the same value from the same code list.

5.1.1.4.1 Payload

The following query header is used by the system and the application to send error messages.

Binary Query Header
Query Type	TLS Message Type	Sequential Number	JSON Size
Notification	Send Internal Error	Unused	Size of the JSON data
0x20	0x000002	0xNNNNNNNN	0xNNNNNNNN
JSON Data
Binary Data: Single Byte Error Code

5.1.1.4.2 JSON structure

Key	Description
id	A decimal value representing an Error code.
text	A string describing the error.

5.1.1.4.3 Error codes

Error code	Byte	Value	Description
ERROR_SUCCESS	0x00	0	Internal Security Manager value
ERROR_INVALID_QUERY_SIZE	0x01	1	Wrong size of query data
ERROR_INVALID_QUERY_ID	0x02	2	Unknown Query ID
ERROR_NOT_SUPPORTED	0x03	3	SDL does not support encryption
ERROR_SERVICE_ALREADY_PROTECTED	0x04	4	Received request to protect a service that was protected before
ERROR_SERVICE_NOT_PROTECTED	0x05	5	Received handshake or encrypted data for not protected service
ERROR_DECRYPTION_FAILED	0x06	6	Decryption failed
ERROR_ENCRYPTION_FAILED	0x07	7	Encryption failed
ERROR_SSL_INVALID_DATA	0x08	8	SSL invalid data
ERROR_HANDSHAKE_FAILED	0x09	9	In case of all other handshake errors
INVALID_CERT	0x0A	10	Handshake failed because certificate is invalid
EXPIRED_CERT	0x0B	11	Handshake failed because certificate is expired
ERROR_INTERNAL	0xFF	255	Internal error
ERROR_UNKNOWN_INTERNAL_ERROR	0xFE	254	Error value for testing

5.2 RPC Service

Required: All Protocol Versions

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.

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.

RPC Payload

Binary Header

JSON Data

5.2.1 Binary Header

Required: Protocol Version 2 and greater

Byte 1		Byte 2	Byte 3	Byte 4
RPC Type	RPC Function ID
Correlation ID
JSON Size

5.2.1.1 Binary Header Fields

Field	Size	Description
RPC Type	4 bit	0x0 Request 0x1 Response 0x2 Notification 0x3 Erroneous Response 0x4 - 0xF Reserved
RPC Function ID	28 bit	The Function ID of each RPC is specific to each version of the RPC Specification but in general do not change from version to version.
Correlation ID	32 bits (signed)	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.
JSON Size	32 bits	The size of the JSON Data following the Binary Header in the RPC Payload

5.3 Hybrid (Bulk Data) Service

Required: Protocol Version 2 and greater

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.

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.

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).

The Binary Header of a message using the Hybrid Service is the same as the Binary Header of a message using the RPC Service.

Hybrid Service Payload

Binary Header

JSON Data

Bulk Data

5.4 Audio Service (PCM)

Available: Protocol Version 3 and greater

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.

5.5 Video Service (H.264)

Available: Protocol Version 3 and greater

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.

6. Ending Communication

The application may request it's session to be ended outside of a transport disconnect, module power cycle, etc.

6.1 Completely Closing a Session and Ending All Services

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.

6.2 Closing Specific Services

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.

7. Secured Communication

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.

Below are possible combinations of the service encryption status and RPCs protection flag value.

Service Encryption Status	RPC Type	Requires Protection	Expected SDL Behavior
Encryption is not established	Request	yes	SDL Core rejects the request with result code `ENCRYPTION_NEEDED` (please see policy updates for which RPCs need protection).
		no	SDL Core continues processing the RPC request.
	Notification	yes	SDL Core does not send the notification.
		no	SDL Core sends the notification unencrypted.
Encryption is established	Request	yes	If unencrypted, SDL Core rejects the request with an unencrypted response and result code `ENCRYPTION_NEEDED`. If encrypted, SDL Core continues processing the request and sends an encrypted response.
		no	If unencrypted, SDL Core continues processing the request and sends an unencrypted response. If encrypted, SDL Core continues processing the request and sends an encrypted response.
	Notification	yes	SDL Core sends the notification encrypted.
		no	SDL Core sends the notification unencrypted.

7.1 Authentication

The authentication is done using TLS handshake. The TLS handshake process is defined by TLS and is not part of the SDL protocol.

The below diagram shows the sequence of how the TLS handshake exchanges certificates to compute the master secret.

Please see SDL Overview Guides for more details.

The system can be configured to support one encryption method. The following methods are supported:

• TLSv1
• TLSv1.1
• TLSv1.2
• DTLSv1
• SSLv3 (not supported on most newer systems)

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.

The system also supports configurable SSL Security level 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.

7.2 Handshake Frames

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.

7.2.1 SDL Protocol Frame Header

The following SDL frame header is used for every frame related to TLS handshake.

SDL Protocol Frame Header
Version	E	Frame Type	Service Type	Frame Info	Session ID	Data Size	Message ID
Max major version supported by module and application	no	Single Frame	Control Service	Single Frame Info	Assigned Session ID	Query Binary Header + JSON Data size + Binary Handshake Data size	Enumerated number
0xN	0b0	0b001	0x00	0x00	0xNN	0xC + 0xNNNNNNNN + 0xNNNNNNNN	0xNNNNNNNN

7.2.2 Security Query Binary Header

The following query header is used by the system and the application to send TLS handshake data.

Binary Query Header
Query Type	TLS Message Type	Sequential Number	JSON Size
Request	Send Handshake Data	Any number to be used to correlate query messages	Zero
0x00	0x000001	0xNNNNNNNN	0x00000000
Binary TLS Handshake Data

7.3 Error handling

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.

protocol_spec's Issues

[SDL 0078] Control Frame Payloads v1.0.0

Proposal: Control Frame Payloads v1.0.0

With the acceptance of Constructed Payloads for Control Frames we need to ensure we spec out all the changes that will be needed for the first version of these payloads. This includes adding a new param to the StartService frame for RPC services that contains the max version supported for control frame payloads.

Review: smartdevicelink/sdl_evolution#222

Steering Committee Decision:

The Steering Committee agreed to accept this proposal, with the following change: Change from introducing a new controlVersion parameter to changing the protocol header to have an extended version for headers, as described in the "Alternatives considered" section. This change has now been reflected in the proposal .md file.

Security message format is not defined

SDL Core uses it's own header format similar to the RPC Binary Frame header in order to perform handshakes or report errors in the handshake process. The Protocol Spec must be changed to include this information.

[SDL 0317] SDL Protocol Security Specification

Proposal: SDL Protocol Security Specification

This proposal adds the documentation and specification around protected communication, encryption and handshake to the SDL protocol specification. It is a collaborated effort with Ford and Luxoft to protect the implemented SDL security from unexpected changes and to allow SDL Evolution proposals to improve it.

Review: smartdevicelink/sdl_evolution#1070

Steering Committee Decision: The Steering Committee voted to accept this proposal with the following revisions:

1. Remove "Note: Communication partners should set this field to zero" from the "Frame Info" and "Data Size" descriptions in the Change 1 table (https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0317-sdl-protocol-security-specification.md#change-1-update-frame-header-fields-description).
2. In Proposed solution section (4.2.5 Start Service), change "See "Secured Communication" section for more details." to "See "7. Secured Communication" section for more details."
3. In Proposed solution section (7. Secured Communication), change "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." to "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 to 1 when the service is already established (this the required flow for the RPC service)."
4. Update Impact on existing code section to remove code changes related to Core/Mobile libraries, and update Impacted Platforms to only include "Protocol".

The proposal .md file was updated to reflect these revisions on 6/10/21

[SDL 0052] Constructed Payloads

Proposal: Constructed Payloads

This proposal is for the addition of constructed payloads for non-RPC type packets. It will allow for clearer definition of payloads and allow for better parsing between versions. Constructed payloads reduce overhead by avoiding having to send an RPC message as well not mixing different services in the process.

Review: smartdevicelink/sdl_evolution#157

Steering Committee Decision:

As this proposal has now been revised to include BSON, the Steering Committee has agreed to accept this proposal.

Re-Link the RPC Specification when it's properly placed in github rather than to sdl_core

[SDL 0058] Add video streaming capabilities

Proposal: Add video streaming capabilities

This proposal extends SDL video streaming feature by 1) notifying video streaming capabilities of HMI to SDL proxy, and 2) adding "video format negotiation" procedure.

Review: smartdevicelink/sdl_evolution#176

Steering Committee Decision:

The Steering Committee has decided to accept this proposal with revisions. The Xevo team (@shoamano83 @jhludwig) revised, based on the discussion in the Steering Committee meeting:

1. Codecs and streaming transports need information in their descriptions to let develops know which ones are currently supported and which ones aren’t.
2. Xevo will create first draft of the fallback streaming combination order.

The following changes were incorporated into the proposal:

1. Added a note that not all video formats are supported yet.
2. Added a suggested mechanism to pick a video format during video negotiation, including a fall back flow.

Note:

Protocol Spec will need to implement Video Streaming Control Capabilities

`pcmCapabilities` Parameter

We need to ensure the Protocol Spec calls out that for an audio streaming service, the default parameters are 16khz and 16 bit.

This was decided during the August 22 Steering Committee Meeting.

Additional details:

smartdevicelink/sdl_core@88e0560

This parameter is an extension of AudioPassThru capabilities used for mobile navigation. The system sends separate capabilities in case the channel has something different than AudioPassThru. Core does send this information back, but the mobile SDK is not consuming and/or making available. By default, the expectation with moblile navigation partners is 16khz and 16 bit. Ford recommends formally exposing this through APIs in SDKs.

Broken Links in RPC Service and Authentication

There are a few broken links in the Protocol Spec which should be fixed.

Current: In 5.2 RPC Service section, there are two instances where "RPC Specification" links to https://github.com/smartdevicelink/sdl_core/blob/master/src/components/interfaces/MOBILE_API.xml, which gives a 404.

Expected: In 5.2 RPC Service section, both instances of "RPC Specification" should link to https://github.com/smartdevicelink/rpc_spec/blob/master/MOBILE_API.xml.

---

Current: In 7.1 Authentication section, "SSL Security Level" links to https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_get_security_level.html, which gives a "Page Not Found" error.

Expected: In 7.1 Authentication section, "SSL Security Level" should link to https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_get_security_level.html.

---

Current: In 7.1 Authentication section, "SDL Overview Guides" links to https://smartdevicelink.com/en/guides/pull_request/sdl-overview-guides/security/protected-services/, which gives a 404.

Expected: In 7.1 Authentication section, "SDL Overview Guides" should link to https://smartdevicelink.com/en/guides/sdl-overview-guides/security/protected-services/.

[SDL 0040] DTLS encryption

Proposal: DTLS encryption

This proposal is to add DTLS (Datagram Transport Layer Security) to SDL core. SDL core will utilize the DTLS communications protocol as a preferred solution when sending encrypted data over protected services (such audio 0x0a and video 0x0b ) including the handshake, encryption and decryption processes.

Review: smartdevicelink/sdl_evolution#126

Steering Committee Decision:

The Steering Committee has agreed to accept this proposal. They've also agreed that we should target Android and iOS library changes as an additional proposal, as this cannot be tested without the library portion.

Need to explicitly call out MTU size for each version of the protocol

SDL 0158 - Cloud App Transport Adapter

Proposal: Cloud App Transport Adapter

This proposal will detail a possible solution for allowing SDL-enabled cloud applications to be used in a vehicle. This proposal will cover the process of obtaining cloud application server endpoints, enabling which cloud apps should appear in the HMI app list, opening connections between Core and a cloud based app server, and how a cloud application can authenticate connected head units.

Review Issue: smartdevicelink/sdl_evolution#493

Revisions to the review issue: smartdevicelink/sdl_evolution#666

Steering Committee Decision:

The Steering Committee voted to accept this proposal with revisions. The revisions will include changing the app_icon_url policy table attribute to icon_url as mentioned in this comment, include the affecting platforms based on the protocol changes mentioned in this comment, and rename cloudAppAuthToken to authToken noted in this comment.
Additionally, the author stated that OEMs have the ability to specify secure websockets or unsecured websockets whether you have WS or WSS specified in cloud_transport_type in the policy table.

Revisions have been made

[SDL 0308] Add a Reason Parameter to All Protocol NAKs

Proposal: Add a Reason Parameter to All Protocol NAKs

As a maintainer of an app library, it is often difficult to understand why Core has NAKed a protocol message. Most NAKs currently have a rejectedParams parameter, but in practice, this has not been enough information to determine why a NAK has occurred and properly alert the developer. In place of the rejectedParams parameter, the RegisterSecondaryTransportNAK has a reason parameter to describe the failure reason. This is a better approach and we should expand it to all NAK parameters.

Review: smartdevicelink/sdl_evolution#1027

The version can never be increased beyond 15, or backward compatibility is broken

See smartdevicelink/sdl_core#17 for more info

Encrypted payloads should not exceed 16384 bytes to match TLS record standard

To ensure compatibility with transport layer security, we should make note when using encrypted protocol messages, the payload should not exceed 16384 bytes to match the maximum available in a standard TLS record. Please see link below for details as well as a pertinent copy / pasted snippet.

https://hpbn.co/transport-layer-security-tls/

Maximum TLS record size is 16 KB Each record contains a 5-byte header, a MAC (up to 20 bytes for SSLv3, TLS 1.0, TLS 1.1, and up to 32 bytes for TLS 1.2), and padding if a block cipher is used. To decrypt and verify the record, the entire record must be available.

[SDL 0280] Adding new parameter of requiresAudioSupport and BluetoothDeviceAddress

Proposal: Adding new parameter of requiresAudioSupport and BluetoothDeviceAddress

In this proposal, by adding the requiresAudioSupport in RegisterAppInterface and the bluetooothDeviceAddress in DeviceInfo, when the device is connected via only USB, head unit (HU) will connect to the SDL device's Bluetooth (BT) automatically or prompt the user requesting BT connection.

Review: smartdevicelink/sdl_evolution#941

Steering Committee Decision:
The Steering Committee voted to accept this proposal with the following revisions:

1. Modify flow chart to incorporate sequence in this comment and revise the section below to include the note about the MediaStreamingStatus class and its usage. For example, if the protocol version is lower, the library could and should check if audio is already connected. Otherwise, apps that require audio support wouldn't connect to anything currently in production.

If the response was a StartServiceACK, requiresAudioSupport was set to true, but the protocol version of the ACK is less than the major version of this feature, the app will shut down.

2. Specify in MediaStreamingStatus class section of proposal, that feature will use value of isAudioOutputAvailable() method, since the MediaStreamingStatus class actually checks for multiple Audio Output options.
3. In MediaStreamingStatus class section, change “…to the preprocessing of the RegisterAppInterface" to "…to the post-processing of StartService ACK or NAK".
4. Specify in proposal that since there aren't any public code changes listed in the proposal, the SDLC Project Maintainer will have discretion over implementation details, including changes to classes that are not accessible to developers, especially given changes to Java Suite library in 5.0 release.

The proposal .md file was updated to reflect these revisions on 10/13/2020.

[SDL 0162] Define Handling of Duplicate Correlation IDs

Proposal: Define Handling of Duplicate Correlation IDs

This proposal is for the clarification of the SDL protocol behavior in the case that an app sends multiple messages with the same correlation ID.

Review: smartdevicelink/sdl_evolution#476

Steering Committee Decision:

The Steering Committee voted to accept this proposal. It was also confirmed by the Project Maintainer during the discussion that this proposal applies to all RPCs, and is trying to clarify that a Correlation ID should never be a duplicate from request to request. A request needs a response before a developer sends the same Correlation ID again in a new request.

[SDL 0293] Enable OEM exclusive apps support

Proposal: Enable OEM exclusive apps support

This feature will enable SDL adopters to provide exclusive apps to their users depending on vehicle type. The proposal describes a way to share vehicle type information before sending the Register App Interface request.

Review: smartdevicelink/sdl_evolution#971

Steering Committee Decision:
The Steering Committee voted to accept this proposal with the following revisions:

The author is to update the proposal to include the requested requirement for the Java Suite Library to have two pull requests submitted for this feature. The reasoning as to why is documented in this comment and should be included in the proposal.

The proposal .md file was updated to reflect these revisions on 12/14/2020.

Ending Communication Flow

Need to find out the following:

We know that services need to be closed with the end service control frame with 4 bytes in the payload that is the hashID. Does this hash ID always come from the payload of a StartServiceACK or is there some other way of getting it for different versions of the protocol?

Can a head unit close the communication session or does it always originate from the phone with an EndService? (What is the behavior when a vehicle turns off while the app is still connected?)

[SDL 0141] Supporting simultaneous multiple transports

Proposal: Supporting simultaneous multiple transports

This proposal aims to support multiple transports between Core and Proxy.

Review: smartdevicelink/sdl_evolution#405

Steering Committee Decision:

The Steering Committee has voted to accept this proposal with revisions. The revisions are as follows:

• Introduce a new Control Frame, RegisterSecondaryTransport, which will be used once a Secondary Transport is connected to notify Core that the Proxy has established a connection and tell Core which session is registering.
• Rename Transport Config Update to TransportEventUpdate. The original parameters will be refactored to a flat structure.
• StartServiceACK for the RPC service will contain a Secondary Transport param that will contain an array of potential secondary transports instead of a single value. The service to transport priority parameters will become flat instead of document style; each service param will contain an ordered array in terms of priority of potential transports.
• Proxy connection retry strategy will include the new TransportEventUpdate Control Frame. When a connection is interrupted/ended, a TransportEventUpdate control frame will be sent to the proxy on the primary transport. If the proxy is to retry (in case of WiFi), it will include the IP address and Port. If the proxy is not to retry, the frame will contain either empty strings for IP address and port or not include the parameters at all.
• Will recommend, but not require, using 5GHz
• Proxy implementations will be discussed outside of this proposal.

The proposal .md was updated on March 16, 2018 to include the agreed upon revisions.

Get a better definition of what is in each protocol version

Right now we're about to release protocol version 4 in each of the libraries and on core but they don't have a full heartbeat or video streaming implementation (on the mobile side). This will cause incompatibility if, for example, a version 3 sdl core starts sending heart beats and doesn't get any response from a version 4 library.

One of our proposals is to rearrange the features that are supported in each version of the protocol. For example, if heartbeat is not supported in the next release of iOS and Android, we might have to move it's support to V 4 instead of V 3.

We also have an issue that Apple changed how canOpenUrl works and so we might have to remove the majority of features in V4.