ETSI TS 103 544-3 V1.3.1 (2019-10)

TECHNICAL SPECIFICATION
Publicly Available Specification (PAS);
Intelligent Transport Systems (ITS); ®
MirrorLink ;
Part 3: Audio
CAUTION
The present document has been submitted to ETSI as a PAS produced by CCC and
approved by the ETSI Technical Committee Intelligent Transport Systems (ITS).
CCC is owner of the copyright of the document CCC-TS-012 and/or had all relevant rights and had assigned said rights to
ETSI on an "as is basis". Consequently, to the fullest extent permitted by law, ETSI disclaims all warranties whether express,
implied, statutory or otherwise including but not limited to merchantability, non-infringement of any intellectual property rights of
third parties. No warranty is given about the accuracy and the completeness of the content of the present document.

2 ETSI TS 103 544-3 V1.3.1 (2019-10)

Reference
RTS/ITS-98-3
Keywords
interface, ITS, PAS, smartphone

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm
except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
©ETSI 2019.
© Car Connectivity Consortium 2011-2019.
All rights reserved.
ETSI logo is a Trade Mark of ETSI registered for the benefit of its Members.
MirrorLink® is a registered trademark of Car Connectivity Consortium LLC.
RFB® and VNC® are registered trademarks of RealVNC Ltd.
UPnP® is a registered trademark of Open Connectivity Foundation, Inc.
Other names or abbreviations used in the present document may be trademarks of their respective owners.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 544-3 V1.3.1 (2019-10)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Introduction . 8
5 Audio Link Options . 9
6 Audio Link Selection. 13
6.1 General . 13
6.2 Identification of Available Audio Links . 13
6.3 LaunchApplication (AppID, ProfileID) . 13
6.4 TerminateApplication (AppID, ProfileID) . 14
6.5 GetApplicationStatus (AppID, ProfileID) . 15
7 RTP Audio Streaming . 16
7.1 General . 16
7.2 RTP Packet Structure and Header Definition . 16
7.3 RTP Audio Payload Definition . 19
7.3.1 General . 19
7.3.2 48 kHz, 16 Bit Audio Payload (Mono) . 19
7.3.3 48 kHz, 16 Bit Audio Payload (Stereo) . 20
7.3.4 16 kHz, 16 Bit Audio Payload (Mono) . 21
7.4 Establishing the RTP Connection . 21
7.4.1 General . 21
7.4.2 RTP Server within MirrorLink Server . 21
7.4.3 RTP Server within MirrorLink Client . 22
7.5 Client and Server Implementation . 22
8 Voice Command Handling . 24
8.1 General . 24
8.2 VC over RTP with an Established VNC Session . 25
8.3 VC over RTP with an Established WFD Session . 29
8.4 VC over RTP without a VNC/WFD Sessio n . 29
8.5 VC over Bluetooth HFP BVRA . 29
9 Interoperability with Bluetooth . 29
9.1 General . 29
9.2 Bluetooth Profiles relevant for MirrorLink . 30
9.3 Interoperability States - MirrorLink Server Perspective . 30
9.4 Interoperability States - MirrorLink Client Perspective . 32
10 Audio Signal Processing Configuration . 33
10.1 Conversational and Telephony-based Audio . 33
10.2 Bluetooth HFP Noise Reduction/Echo Cancellation . 34
10.3 RTP-based Conversational Audio . 34
10.4 RTP-based Voice Command Audio . 34
11 Latency Switching Sources . 34
11.1 General . 34
ETSI
4 ETSI TS 103 544-3 V1.3.1 (2019-10)
11.2 Protocol Behaviour of Latency Switching Sources . 34
11.3 Timing Behaviour of Latency Switching Sources . 35
11.4 Use Cases for Latency Switched Sources . 36
11.5 Backward Compatibility of Latency Switched Sources . 38
Annex A (informative): Authors and Contributors . 39
History . 40

ETSI
5 ETSI TS 103 544-3 V1.3.1 (2019-10)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Intelligent Transport Systems
(ITS).
The present document is part 3 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.1].
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
6 ETSI TS 103 544-3 V1.3.1 (2019-10)
1 Scope ®
The present document is part of the MirrorLink specification which specifies an interface for enabling remote user
interaction of a mobile device via another device. The present document is written having a vehicle head-unit to interact
with the mobile device in mind, but it will similarly apply for other devices, which provide a color display, audio
input/output and user input mechanisms.
The present document defines the MirrorLink Audio architecture, based on an RTP forward and back channel, plus an
possible Bluetooth HFP and A2DP setup.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Applications", July 2003.
NOTE: Available at http://tools.ietf.org/html/rfc3550.
[2] Bluetooth Specification: "Hands-free Profile", Audio, Telephony, and Automotive Working
Group, Revision 1.7.2, January 21, 2019.
NOTE: Available at https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=457090.
[3] Bluetooth Specification: "Headset Profile", Car Working Group, Revision V12r00, December 18,
2008.
NOTE: Available at https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=158743.
[4] Bluetooth Specification: "Advanced Audio Distribution Profile", Audio, Telephony, and
Automotive Working Group, Revision 1.3.2, January 21, 2019.
NOTE: Available at https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=457083.
[5] IETF RFC 2190: "RTP Payload Format for H.263 Video Streams", September 1997.
NOTE: Available at http://tools.ietf.org/html/rfc2190.
[6] IETF RFC 3551: "RTP Profile for Audio and Video Conferences with Minimal Control", July
2003.
NOTE: Available at http://tools.ietf.org/html/rfc3551.
[7] ETSI TS 103 544-12 (V1.3.1): "Intelligent Transport Systems (ITS); MirrorLink®; Part 12: UPnP
Server Device".
[8] ETSI TS 103 544-9 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 9: UPnP Application Server Service".
[9] ETSI TS 103 544-10 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 10: UPnP Client Profile Service".
ETSI
7 ETSI TS 103 544-3 V1.3.1 (2019-10)
[10] ETSI TS 103 544-15 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink® ; Part 15: Application Programming Interface (API) Level 1 & 2".
[11] ETSI TS 103 544-2 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink® ; Part 2: Virtual Network Computing (VNC) based Display and
Control".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 103 544-1 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 1: Connectivity".
[i.2] ITU-T Recommendation G.114 (05/2003): "One-way transmission time", May 6, 2003.
NOTE: Available at https://www.itu.int/rec/T-REC-G.114-200305-I/en.
[i.3] ITU-T Recommendation P.1100 (03/2017): "Narrowband hands-free communication in motor
vehicles", March 1, 2017.
NOTE: Available at https://www.itu.int/rec/T-REC-P.1100-201703-S/en.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
pointer event: touch screen action in which the user touches the screen with one (virtual) finger only at a single
location
touch event: touch screen action in which the user touches the screen with two or more separate fingers at different
locations
NOTE: Touch events are used to describe more complex touch action, like pinch-open or pinch-close.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
A2DP Bluetooth Advanced Audio Distribution Profile
API Application Programming Interface
BT Bluetooth
BTA2DP Bluetooth Advanced Audio Distribution Profile
BTHFP Bluetooth Hands Free Profile
ETSI
8 ETSI TS 103 544-3 V1.3.1 (2019-10)
BVRA Bluetooth Voice Recognition Activation
CC CSRC Count
CE Consumer Electronics
NOTE: CE devices are referred to as mobile devices within the present document.
CSRC Contributing SouRCe
HFP Bluetooth Hands-free Profile
HS Head-Set
HSP Bluetooth Headset Profile
HU Head-Unit
NOTE: This term is used interchangeably with the MirrorLink Client.
IOP InterOPerability
IP Internet Protocol
IPL Initial Playback Latency
LSS Latency Switching Sources
MAC Mediaum Access Control
ML MirrorLink
MPL Maximum Playback Latency
PT Payload Type
RFB Remote Framebuffer
RTP Real-time Transport Protocol
SCO Synchronous Connection-Oriented
SOAP Simple Object Access Protocol
SSRC Synchronization SouRCe
UDP User Datagram Protocol
UI User Interface
UIBC User Interface Back Channel
UPnP Universal Plug and Play
URI Uniform Resource Identifier
VC Voice Control
VNC Virtual Network Computing
WFD Wi-Fi Display
XML eXtensible Markup Language
4 Introduction
The present document defines how the MirrorLink Client selects the transport media that the MirrorLink Server shall
use to route audio streams. The MirrorLink Server distinguishes between two audio streams, namely phone and
application audio. It advertises available transport options, using UPnP TmServerDevice:1 services. Audio streams are
specified for the following remote access protocols:
• RTP Real-Time Transport Protocol
• BTA2DP Bluetooth Advanced Audio Distribution Profile
• BTHFP Bluetooth Hands Free Profile
It is the MirrorLink Client's responsibility to select from the advertised audio transport mechanisms how the MirrorLink
Server shall stream the different audio sources. The audio link selection is done according the following priorities
(highest priority first):
1) Keep existing Bluetooth HFP or A2DP connection to another external device, which is not a MirrorLink
Client, if overriding the resource assignment is not allowed.
2) Follow audio link selection using the mechanism described in this clause.
3) Manual Bluetooth pairing (same behaviour as in non-MirrorLink use cases).
MirrorLink Server's speaker shall not be used for audio output.
ETSI
9 ETSI TS 103 544-3 V1.3.1 (2019-10)
MirrorLink Server's microphone shall not be used, for voice input if the MirrorLink Client indicates support for voice
command within its UPnP Client Profile.
The present document allows for different transport mechanisms based on the selections the MirrorLink Client has
taken.
The MirrorLink audio architecture, as shown in Figure 1, allows using the Real-time Transport Protocol for streaming
audio captured from the mobile device, to the MirrorLink Client. The audio output from the mobile device is streamed
in an application agnostic manner so that it does not require re-design or modification of existing applications running
on the device.
Audio Audio Audio Speaker Audio
Server Client & Micro
Client Server
Consumer
Automotive
Electronics
Head Unit
Device
Audio / Voice
Figure 1: Audio Setup
The present document covers both audio output from and audio input to the MirrorLink Server device. Unless otherwise
stated, the present document applies for the audio server and the audio client in the same way:
• The audio output will be handled from the audio server on the MirrorLink Server and the audio client on the
MirrorLink Client.
• The audio input will be handled from the audio client on the MirrorLink Server and the audio server on the
MirrorLink Client.
In addition to RTP, the MirrorLink specification allows regular Bluetooth audio connectivity for both phone and media
audio streams.
5 Audio Link Options
MirrorLink allows the MirrorLink Client and Server to use the following audio features:
• Media - Streaming of media audio from the MirrorLink Server to the MirrorLink Client; media audio feature
includes navigation audio.
• Phone - Bidirectional streaming of conversational audio, including in-band ringing.
• VC - Streaming of voice command (VC) audio from the MirrorLink Client to the MirrorLink Server.
The above listed audio features are available over the following connectivity options:
• Bluetooth (BT).
• RTP.
The MirrorLink Server shall advertise the audio features and connectivity options it supports within the UPnP
A_ARG_TYPE_AppList application listings. The MirrorLink Server shall advertise individual audio components, with
all combinations of the supported audio content categories.
EXAMPLE: If the MirrorLink supports an RTP Server for Media and Phone Audio, it shall advertise three RTP
Servers, one showing Media, one Phone, and one Media & Phone support.
ETSI
10 ETSI TS 103 544-3 V1.3.1 (2019-10)
This will allow the MirrorLink Client to specifically inform the MirrorLink Server, which feature it is going to use. The
possible audio content categories for the different audio components are listed below:
• RTP Client: Phone Audio, Voice Command In, Phone Audio + Voice Command In.
• RTP Server: Media Audio Out, Phone Audio + Media Audio Out.
• BT A2DP: Media Audio Out.
• BT HFP: Phone Audio, Phone Audio + Voice Command In.
The MirrorLink Server shall include the RTP Server with a value of audioInfo@contentCategory equaling Media
Audio Out (0x01) first in the list of advertised RTP Servers for the same RTP payload types
(A_ARG_TYPE_AppList).
If the MirrorLink Server supports Voice Command over RTP, it shall include the RTP Client with a value of
audioInfo@contentCategory equaling Voice Command In (0x10) first in the list of advertised RTP Clients for
the same RTP payload types (A_ARG_TYPE_AppList).
The MirrorLink Client shall select the audio features and their connectivity option, which the MirrorLink Client is
going to use. The MirrorLink Client shall use the UPnP Application Server service's Launch Application action to
inform the MirrorLink Sever about its selection. The MirrorLink Client shall not launch more than one RTP Client,
RTP Server, BT HFP, and BT A2DP component.
Based on the set of audio components, launched from the MirrorLink Client, the MirrorLink Server and Client shall use
specific audio links for Media, Phone and Voice Command use cases. Table 1 lists the possible combinations of audio
features and their underlying connectivity options on the left side. For each combination, the required audio components
are listed, which shall be launched from the MirrorLink Client to enable it. Note, that some Audio Feature Set
combinations are not possible. The below table shall not be used in case a WFD session, introduced in MirrorLink 1.2,
is established.
Table 1: UPnP Negotiation for Audio Selection (Non-WFD Case)
Audio Feature Combinations and Audio Components launched from the MirrorLink Client to
underlying Connectivity enable the Audio Feature Combination
Media Phone VC BT HFP BT A2DP RTP Server RTP Client
- - - - - - -
- - RTP - - - VC
- - BT Not possible
- RTP - - - Phone Phone
- RTP RTP - - Phone Phone + VC
- RTP BT Not possible
- BT - Phone - - -
- BT RTP Phone - - VC
- BT BT Phone + VC - - -
RTP - - - - Media -
RTP - RTP - - Media VC
RTP - BT Not possible
RTP RTP - - - Phone + Media Phone
RTP RTP RTP - - Phone + Media Phone + VC
RTP RTP BT Not possible
RTP BT - Phone - Media -
RTP BT RTP Phone - Media VC
RTP BT BT Phone + VC - Media -
BT - - - Media - -
BT - RTP - Media - VC
BT - BT Not possible
ETSI
11 ETSI TS 103 544-3 V1.3.1 (2019-10)
Audio Feature Combinations and Audio Components launched from the MirrorLink Client to
underlying Connectivity enable the Audio Feature Combination
Media Phone VC BT HFP BT A2DP RTP Server RTP Client
BT RTP - - Media Phone Phone
BT RTP RTP - Media Phone Phone + VC
BT RTP BT Not possible
BT BT - Phone Media - -
BT BT RTP Phone Media - VC
BT BT BT Phone + VC Media - -
NOTE: Entries marked as Not possible in these tables are meant to describe combinations, which are out of
scope from the MirrorLink specification. Behaviour, if supported, is implementation dependent. Entries
should not be used.
BT HFP and BT A2DP may be connected outside the MirrorLink session, i.e. without specifically using the UPnP
mechanisms to launch those. In that case the MirrorLink Client and Server shall make the selection based on the
following table. Components marked with Legacy shall not be launched using the UPnP TmApplicationServer
service's LaunchApplication action. The setup of the legacy Bluetooth connection is outside the scope of the MirrorLink
specifications. The below table shall not be used in case a WFD session, introduced in MirrorLink 1.2, is established.
Table 2: UPnP Negotiation for Audio Selection with Legacy Bluetooth (Non-WFD Case)
Audio Feature Set and underlying Audio Components launched from the MirrorLink Client to
Connectivity enable the Audio Feature Set
Media Phone VC BT HFP BT A2DP RTP Server RTP Client
- BT - Legacy - - -
- BT RTP Legacy - - VC
- BT BT Legacy - - -
RTP BT - Legacy - Media -
RTP BT RTP Legacy - Media VC
RTP BT BT Legacy - Media -
BT - - - Legacy - -
BT - RTP - Legacy - VC
BT - BT Not possible
BT RTP - - Legacy Phone Phone
BT RTP RTP - Legacy Phone Phone + VC
BT RTP BT Not possible
BT BT - Legacy Legacy - -
BT BT RTP Legacy Legacy - VC
BT BT BT Legacy Legacy - -
If an audio use feature is not covered from the audio component selection, done by the MirrorLink Client, the
MirrorLink Server shall fallback to its default configuration.
MirrorLink 1.2 introduces Wi-Fi Display (WFD) based audio/video streaming for MirrorLink. The use of WFD
removes the need to setup a separate RTP forward channel to carry media audio. The MirrorLink Server shall stream
media audio via WFD RTP streaming.
ETSI
12 ETSI TS 103 544-3 V1.3.1 (2019-10)
Based on the set of audio components, launched from the MirrorLink Client, the MirrorLink Server and Client shall use
specific audio links for additional Phone and Voice Command use cases. Table 1 lists the possible combinations of
audio features and their underlying connectivity options on the left side. For each combination, the required audio
components are listed, which shall be launched from the MirrorLink Client to enable it. Note, that some Audio Feature
Set combinations are not possible.
Table 3: UPnP Negotiation for Audio Selection (WFD Case)
Audio Feature Combinations and Audio Components launched from the MirrorLink Client
underlying Connectivity to enable the Audio Feature Combination
Media Phone VC BT HFP BT A2DP RTP Server RTP Client
- { -, WFD, BT } { -, RTP, BT } Not possible
WFD - - - - { -, Media } -
WFD - RTP - - { -, Media } VC
WFD - BT Not possible
WFD WFD - - - { -, Media } Phone
WFD WFD RTP - - { -, Media } Phone + VC
WFD WFD BT Not possible
WFD BT - Phone - { -, Media } -
WFD BT RTP Phone - { -, Media } VC
WFD BT BT Phone + VC - { -, Media } -
BT { -, WFD, BT } { -, RTP, BT } Not possible

The MirrorLink Server shall not stream media audio content via a separate RTP Server, even if that RTP Server has
been individually launched from the MirrorLink Client. The MirrorLink Client may launch the MirrorLink Server's
RTP Server to allow for a faster handover from a WFD to a Non-WFD based audio streaming.
The MirrorLink Server shall transition media audio content to the RTP Server, if it has been launched from the
MirrorLink Client, when the WFD session is disconnected. The MirrorLink Server shall transition media audio content
from a launched RTP Server (or BT A2DP) to WFD, once the WFD session is established.
BT HFP may be connected outside the MirrorLink session, i.e. without specifically using the UPnP mechanisms to
launch those. In that case the MirrorLink Client and Server shall make the selection based on the following table.
Components marked with Legacy shall not be launched using the UPnP Application Server service's Launch
Application action. The setup of the legacy Bluetooth connection is outside the scope of the MirrorLink specifications.
Table 4: UPnP Negotiation for Audio Selection with Legacy Bluetooth (WFD Case)
Audio Feature Set and underlying Audio Components launched from the MirrorLink
Connectivity Client to enable the Audio Feature Set
Media Phone VC BT HFP BT A2DP RTP Server RTP Client
- { -, WFD, BT } { -, RTP, BT } Not possible
WFD BT - Legacy - { -, Media } -
WFD BT RTP Legacy - { -, Media } VC
WFD BT BT Legacy - { -, Media } -
BT { -, WFD, BT } { -, RTP, BT } Not possible

BT A2DP shall not be used in a WFD session. A legacy BT A2DP connection shall be disconnected.
ETSI
13 ETSI TS 103 544-3 V1.3.1 (2019-10)
6 Audio Link Selection
6.1 General
The TmApplicationServer:1's service shall be used for controlling audio streams. Each type of audio source or sink on
the MirrorLink Server is considered a remote application which can be remotely controlled by the MirrorLink Control
Point using TmApplicationServer:1 service.
The audio servers and clients can be started and terminated the same way as any other remote application using the
LaunchApplication() and TerminateApplication() SOAP actions respectively. The audio server, optionally running as
part of the MirrorLink Client, will provide audio input like voice control to the MirrorLink Server.
Next a description is provided of how TmApplicationServer:1's SOAP actions are utilized to select the audio links. Note
that only the aspects specific to audio link selection are covered here and the reader is REQUIRED to refer to the
corresponding service specification for complete details of the TmApplicationServer:1.
The MirrorLink Client should make the audio link selection not later than 10 s after receiving the first
A_ARG_TYPE_AppList response from the MirrorLink Server.
The MirrorLink Client shall have made the audio link selection prior starting the first VNC based remote application.
6.2 Identification of Available Audio Links
The identification of audio links is described in [8].
6.3 LaunchApplication (AppID, ProfileID)
The LaunchApplication() action shall be used to start the audio streaming on the MirrorLink Server side and therefore
select the underlying audio link. The response received will be an URI to the audio streaming sources/sinks using the
audio streaming protocol identifier. The URI shall follow the A_ARG_TYPE_URI definition as specified in [8].

Figure 2: Message Flow - Launch Audio Link
The message flow for selecting an audio link, using LaunchApplication(), as shown in Figure 2, consists of the
following steps:
1) MirrorLink UPnP Control Point: Call GetApplicationList() SOAP action.
2) MirrorLink UPnP Server: Return A_ARG_TYPE_AppList, which includes a list of available audio servers.
ETSI
14 ETSI TS 103 544-3 V1.3.1 (2019-10)
3) MirrorLink Client: Select the preferred audio server, using the protocolID and direction elements:
a) BT only: Prepare for BT connection, if MirrorLink Server is expected to initiate the BT connection.
NOTE: The MirrorLink Client can indicate to the server via the SetClientProfile action that the server has to
initiate the BT connection. By default, the MirrorLink Server will not start the BT connection.
4) MirrorLink UPnP Control Point: Call LaunchApplication() SOAP action containing respective audio server
application ID.
5) MirrorLink Server: Start selected audio server:
a) Determine new audio link configuration, using Table 1.
b) RTP only: Prepare RTP streaming; RTP streaming is done over UDP.
c) BT only: Prepare for BT connection.
d) BT only: Initiate BT connection if MirrorLink Server is expected to initiate the BT connection.
6) MirrorLink UPnP Server: Return A_ARG_TYPE_URI representing the audio server URI
7) MirrorLink Client: Start audio client:
a) RTP only: Connect to RTP streaming port.
b) BT only: Initiate BT connection, if MirrorLink Client is expected to initiate the BT connection.
Using LaunchApplication() will enable a specific audio link. This link is valid until TerminateApplication() action with
the same AppID is called, or the MirrorLink session is closed.
If Bluetooth is already turned on, the MirrorLink Server shall accept BT connection requests after responding to
launching a specific Bluetooth profile. If Bluetooth is turned off, the MirrorLink Server may switch on Bluetooth before
responding to launching a specific Bluetooth profile.
The MirrorLink Server shall only initiate a Bluetooth connection, if the MirrorLink Client has specifically requested the
server to do so, setting in A_ARG_TYPE_ClientProfile to "false". To ensure automatic pairing,
without user intervention, the MirrorLink Client should provide its Bluetooth MAC address (bdAddr) in
A_ARG_TYPE_ClientProfile.
If the MirrorLink Server does not support Bluetooth connection initialization, i.e. it has specifically set
in the UPnP TmServerDevice:1 device XML to "false" [7], and the MirrorLink Client does not
support Bluetooth connection initialization either, the MirrorLink Client shall not use the LaunchApplication() to start a
Bluetooth connection.
6.4 TerminateApplication (AppID, ProfileID)
The TerminateApplication() action shall be used to stop the audio streaming (in either direction) on the MirrorLink
Server side and follows the specification [8]. Invoking the TerminateApplication action causes the corresponding audio
link to be closed.
ETSI
15 ETSI TS 103 544-3 V1.3.1 (2019-10)

Figure 3: Message Flow - Terminate Audio Link
The message flow for unselecting an audio link, using TerminateApplication(), as shown in Figure 3, consists of the
following steps:
1) MirrorLink UPnP Control Point: Call TerminateApplication() SOAP action containing respective audio server
application ID.
2) MirrorLink Server: Stop audio server:
a) Determine new audio link configuration, using Table 1.
b) RTP only: Stop the RTP streaming.
c) BT only: Disconnect BT profile; optionally power down BT.
3) MirrorLink UPnP Server: Return termination success response (true or false).
4) MirrorLink Client: Stop audio client:
a) RTP only: Disconnect from RTP streaming port.
b) BT only: Disconnect BT profile; optionally power down BT.
In case the TerminateApplication() action is used to terminate the audio server residing in the MirrorLink Server device
then the MirrorLink Client will stop receiving the audio stream from the MirrorLink Server.
In case the TerminateApplication() action is used to terminate the audio client residing in the MirrorLink Server then
the MirrorLink Server will stop receiving the audio stream from the MirrorLink Client.
6.5 GetApplicationStatus (AppID, ProfileID)
The GetApplicationStatus() action provides the current status of an audio server or client running on the MirrorLink
Server and is following [8].
The return values (of the type A_ARG_TYPE_AppStatus) specified for this SOAP action can be any of the following:
• Foreground: Audio link is launched.
• Background: Not used.
• Notrunning: Audio link is terminated / not launched.
ETSI
16 ETSI TS 103 544-3 V1.3.1 (2019-10)
7 RTP Audio Streaming
7.1 General
The audio RTP server and client on the MirrorLink Server listen on pre-specified ports, which are advertised using
UPnP mechanisms.
When the audio server captures audio data, it will encode the audio into RTP packets using the negotiated RTP Payload
type and transmit the RTP packets over UDP/IP.
The audio client is fully responsible for receiving and decoding the data packets and restoring the packet order if they
arrive in out of order sequence. More detailed information about the RTP packet structure can be found later in the
present document.
The MirrorLink Server shall support RTP audio streaming for unidirectional audio to the MirrorLink Client. The
MirrorLink Client shall support RTP audio streaming for unidirectional audio from the MirrorLink Server. The
MirrorLink Server may support RTP audio streaming for bi-directional audio.
NOTE: If bi-directional RTP streaming is not supported, telephony use cases work only if BT HFP is supported.
7.2 RTP Packet Structure and Header Definition
RTP packets contain the standard RTP message header and the payload. Usually each RTP packet audio payload
contains a predefined amount of audio data, but in a special case of end of stream (M=1), payload can be zero length.
Therefore, the RTP client should not assume fixed payload length. Each RTP packet audio payload contains predefined
amounts of audio data. Audio samples are sent in sequential order (in sampling order, first sample first).
Each RTP packet contains the standard header as defined in IETF RFC 3550 [1]. The header fields and their default
values are described in the following clause. The RTP packet structure is shown in Table 5.
Table 5: RTP Packet Header Definition
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
V P X CC M PT Sequence Number
Timestamp
SSRC
CSRC [0.15]
NOTE: The RTP header definition keeps the IETF format for numbering bits. Therefore, the most significant bit
is 0 for all RTP header and payload descriptions.
The first twelve octets are present in every RTP packet, while the list of CSRC identifiers is present only when inserted
by a mixer. The following fields are the RTP specification, unless otherwise mentioned:
• Version (V): 2 bits
The RTP version defined by the present document is two (2).
• Padding (P): 1 bit
If the padding bit is set, the packet contains one or more additional padding octets at the end which are not part
of the payload.
• Extension (X): 1 bit
If the extension bit is set, the fixed header shall be followed by exactly one header extension. If the RTP
header carries information about the audio category and application id, then this bit shall be one (1).
ETSI
17 ETSI TS 103 544-3 V1.3.1 (2019-10)
• CSRC Count (CC): 4 bits
The CSRC count contains the number of CSRC identifiers that follow the fixed header.
• Marker (M): 1 bit
The interpretation of the marker is defined (in reference to IETF RFC 2190 [5]);
0: More packets will follow.
1: Current package carries the end of stream; audio client may use this information to e.g. empty any available
receive buffer.
• Payload Type (PT): 7 bits
This field identifies the format of the RTP payload and determines its interpretation by the application.
• Sequence Number: 16 bits
The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to
detect packet loss and to restore packet sequence.
• Timestamp: 32 bits
The timestamp reflects the sampling instant of the first octet in the RTP data packet. The initial value of the
timestamp is random.
• SSRC Synchronization Source: 32 bits
This field identifies the synchronization source.
• CSRC Contributing Source: 32 bits
An array of 0 to 15 CSRC elements identifying the contributing sources for the payload contained in this
packet. The number of identifiers is given by the CC field. should not be used, as the RTP extension header
contains respective information.
If the RTP header carries information about the audio sources, the RTP extension header shall be used as shown in
Table 6. The RTP header extension shall follow clause 5.3.1 of IETF RFC 3550 [1].
Table 6: RTP Packet Header Extension
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Profile Identifier Length
Header Extension::Application Identifier
Header Extension::Application Category

• Profile Identifier: 16 bits
Profile identifier for the extension header; shall be 0x388C.
• Length: 16 bits
Number of 32-bit words for the extension, excluding the extension header (therefore 0 is a valid length).
Length shall be an even number.
• Header Extension: Array of 64 bits
In case of a length of greater than zero, the Header Extension consists of one or more entries of 64 bits each.
Each 64-bit entry references one application contributing to the audio content within the RTP payload. The
entry with the highest priority shall be given first. Other entries shall follow in decreasing priority order.
Priority order is defined by the weights of the audio entries within the audio mixing stage.
ETSI
18 ETSI TS 103 544-3 V1.3.1 (2019-10)
The MirrorLink Ser
...