ETSI TS 103 756 V1.1.1 (2021-11)

Emergency Communications (EMTEL); PEMEA Instant Message Extension

DTS/EMTEL-00053

General Information

• Status: Not Published
• Technical Committee: EMTEL - Emergency Communications
• Current Stage: 12 - Completion
• Due Date: 06-Dec-2021
• Completion Date: 29-Nov-2021

Standards Content (Sample)

TECHNICAL SPECIFICATION
Emergency Communications (EMTEL);
PEMEA Instant Message Extension

2 ETSI TS 103 756 V1.1.1 (2021-11)

Reference
DTS/EMTEL-00053
Keywords
application, emergency
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

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
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2021.
All rights reserved.
ETSI
3 ETSI TS 103 756 V1.1.1 (2021-11)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive summary . 5
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 PEMEA capability extensions . 9
4.1 Overview of extension in PEMEA . 9
4.2 Service support indication and response . 9
4.2.1 Service definition . 9
4.2.2 Service support indication . 9
4.2.3 Service support response . 10
5 Security. 10
5.1 Transport security . 10
5.2 Security token usage . 10
6 Procedures and signalling . 10
6.1 Service invocation . 10
6.1.1 Service invocation procedures . 10
6.1.2 Service invocation object . 11
6.2 Chat-room creation and deletion . 12
6.3 Chat-room creation, JOIN, and ERROR signalling . 12
6.3.1 Semantics . 12
6.3.2 IM service invocation . 13
6.3.3 JOIN message flow . 14
6.3.4 ERROR message flow . 14
6.4 TEXT_MESSAGE flow . 16
6.5 REPLY message signalling . 16
6.6 Message translations and signalling . 17
6.6.1 Overview of the translation functionality . 17
6.6.2 TEXT_MESSAGE translation example . 19
6.6.3 REPLY message translation example . 20
6.7 Disconnects and reconnects . 20
7 IM PEMEA message and type definitions . 21
7.1 Overview . 21
7.2 Data types . 22
7.2.1 languageList . 22
7.2.2 room . 22
7.2.3 timestamp . 22
7.2.4 user. 22
7.2.5 userInfo . 23
7.2.6 message . 23
7.3 JOIN message . 24
7.3.1 Message overview . 24
7.3.2 Examples . 24
ETSI
4 ETSI TS 103 756 V1.1.1 (2021-11)
7.4 ERROR message . 24
7.4.1 Message overview . 24
7.4.2 Examples . 25
7.5 USER_LIST message . 25
7.6 TEXT_MESSAGE message . 26
7.7 REPLY message . 26
7.8 TRANSLATION message . 27
Annex A (normative): IM/PEMEA JSON schema . 29
A.1 General . 29
A.2 IM invocation schema . 29
A.3 IM Definitions schema . 29
A.4 IM JOIN schema . 30
A.5 IM ERROR schema . 31
A.6 IM REPLY schema . 31
A.7 IM TEXT_MESSAGE schema . 32
A.8 IM TRANSLATION schema . 33
A.9 IM USER_LIST schema . 33
Annex B (informative): Recommended TLS cipler suits . 35
History . 36

ETSI
5 ETSI TS 103 756 V1.1.1 (2021-11)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
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.
Foreword
This Technical Specification (TS) has been produced by ETSI Special Committee Emergency Communications
(EMTEL).
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.
Executive summary
The Pan-European Mobile Emergency Application (PEMEA) architecture provides a framework to enable applications
supporting emergency calling functionality to contact emergency services while roaming. PEMEA caters for a range of
extension capabilities, including Instant Messaging (IM) which provides a text-based chat capability between the App
user and the PSAP. The present document provides a specification for an IM capability for PEMEA.
ETSI
6 ETSI TS 103 756 V1.1.1 (2021-11)
Introduction
Instant Message (IM) is commonly referred to as chat and the two terms are used interchangeably in the present
document.
The document assumes a working knowledge of PEMEA and familiarity with the PEMEA specification ETSI
TS 103 478 [1]. Terms common to the PEMEA specification are not redefined or explained in detail in the present
document.
ETSI
7 ETSI TS 103 756 V1.1.1 (2021-11)
1 Scope
The present document describes the PEMEA Instant Message capability for PEMEA and the need for this functionality.
The required entities and actors are identified along with the protocol, specifying message exchanges between entities.
The message formats are specified and procedural descriptions of expected behaviours under different conditions are
detailed.
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] ETSI TS 103 478 (V1.2.1): "Emergency Communications (EMTEL); Pan-European Mobile
Emergency Application".
[2] IANA language subtag registry.
NOTE: Available at http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry.
[3] IETF RFC 2617: "HTTP Authentication Basic Digest Access Authentication", June 1999.
[4] IETF RFC 6750: "The Oauth 2.0 Authorization Framework: Bearer Token Usage", October 2012.
[5] PEMEA Instant Message JSON Schema forge repository.
NOTE: Available at https://forge.etsi.org/rep/emtel/ts-103-756/json-schema.
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] IETF RFC 6753: "A Location Dereference Protocol Using HTTP-Enabled Location Delivery
(HELD)", October 2012.
[i.2] Open Mobile Alliance OMA-TS-MLP-V3-2-20110719-A: "Mobile Location Protocol 3.2"
July 2011.
[i.3] Open Mobile Alliance OMA-TS-MLP-V3-3-1-20111117-A: "Mobile Location Protocol 3.3.1",
November 2011.
ETSI
8 ETSI TS 103 756 V1.1.1 (2021-11)
[i.4] Open Mobile Alliance OMA-TS-MLP-V3-4-20150512-A: "Mobile Location Protocol 3.4",
May 2015.
[i.5] IETF RFC 7519: "JSON Web Token (JWT)", May 2015.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
security: techniques and methods used to ensure:
• authentication of entities accessing resources or data;
• authorization of authenticated entities prior to accessing or obtaining resources and/or data;
• privacy of user data ensuring access only to authenticated and authorized entities;
• secrecy of information transferred between two authenticated and authorized entities.
trusted: identity of entity assured through an approved authentication mechanism and the entity authorized to perform
the action
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AP Application Provider
App Application
EDS Emergency Data Send (message)
ETSI European Telecommunications Standards Institute
HELD HTTP-Enabled Location Delivery
HTTP Hyper-Text Transfer Protocol
IETF Internet Engineering Task Force
IM Instant Messenger
JSON JavaScript Object Notation
MLP Mobile Location Protocol
Pa PEMEA Application to AP interface
PEMEA Pan-European Mobile Emergency Application
PIM PSAP Interface Module
PSAP Public Safety Answering Point
PSP PSAP Service Provider
SIP Session Initiation Protocol
SIPS SIP Secure
TLS Transport Layer Security
tPSP terminating PSP
URI Uniform Resource Identifier
UTC Coordinated Universal Time
ETSI
9 ETSI TS 103 756 V1.1.1 (2021-11)
4 PEMEA capability extensions
4.1 Overview of extension in PEMEA
PEMEA extension capabilities are defined in ETSI TS 103 478 [1] and are implemented through the use of "reach-
back" URIs. The Application Provider (AP) node advertises capabilities as part of the initial forward message through
the network, the Emergency Data Send (EDS) message, and the terminating PSAP Service Provider (PSP) or PSAP
responds with a the subset of capabilities that it supports, thus binding the emergency session between the AP and the
terminating emergency node.
Specifically, the capabilities are sent as information elements in the apMoreInformation element of the EDS message.
The information element and apMoreInformation structures are defined in clauses 10.3.11 and 10.3.12 of
ETSI TS 103 478 [1]. An information element in a PEMEA EDS message identifies a capability and each capability is
made up of three distinct parts:
• typeOfInfo: what function does the information element serve;
• protocol: the specific semantics for using the function;
• value: the URI through which the service is invoked.
Table 10 in ETSI TS 103 478 [1] identifies an initial set of "typeOfInfo" values used to specify a range of capability
extensions for PEMEA. However, beyond the Location_Update and SIP_Request values described in Table 11 of
ETSI TS 103 478 [1], protocols are left for further study and definition in subsequent specifications such as the present
document.
4.2 Service support indication and response
4.2.1 Service definition
ETSI TS 103 478 [1] defines the instant message, "IM", typeOfInfo in Table 10, but does not elaborate further on
protocols in Table 11. The present document provides a concrete definition of the "IM" typeOfInfo in PEMEA through
the specification of a protocol value.
Table 1: Extended AP Information Type Protocol Registry
Info type Value Protocol Token Description
Location_Update HELD_Deref Location requested using a HELD location request per the HELD
de-reference specification [i.1].
MLP_3.2 Mobile Location Protocol Version 3.2 [i.2]
MLP_3.3 Mobile Location Protocol Version 3.3 [i.3].
MLP_3.4 Mobile Location Protocol Version 3.4 [i.4].
SIP_Request sip Requesting a PSAP/PSP SIP URI to which the device can send an INVITE.
sips Requesting a PSAP/PSP SIPS URI to which the device can send an INVITE.
IM PEMEA Instant Messaging functionality is supported using the PEMEA message
exchange protocol.
NOTE: The PEMEA message exchange protocol is specified in clause 6 of the present document.

4.2.2 Service support indication
AP needing to indicate that the Application it is serving can support instant messaging using the PEMEA protocol
would include the following information element in the apMoreInformation element of the EDS associated with the
emergency session:

https://ap.example.pemea.help/48sne8aopaop

ETSI
10 ETSI TS 103 756 V1.1.1 (2021-11)
4.2.3 Service support response
A terminating node that can support the "IM" "PEMEA" capability includes this capability in the apMoreInformation
element returned to the AP in the onCapSupportPost. This is described in clause 11.1.4 of ETSI TS 103 478 [1] with the
value for "IM" "PEMEA" provided in the example below.



5 Security
5.1 Transport security
The chat-room service is identified to potential room participants as an HTTPS URI. The connection is made using
TLS 1.3 but may be made using TLS 1.2 but shall not fallback below TLS 1.2. The connecting participant shall
authenticate to the chat-room service using domain certificates and a Bearer token [4]. Once the connecting entity is
authenticated and authorization granted the connection is upgraded to a websocket. The websocket is expected to
remain open while the entity is "online". The protocol is resilient to connections being dropped, so an entity may
reconnect as long as the EDS session remains active in the PSAP.
The lists for the TLS 1.3 and TLS 1.2 acceptable cipher suites are included in annex B. These lists are informative and
are based on best information at the time of writing. Older cipher suites not included in either of these lists shall not be
used.
5.2 Security token usage
The HTTP Authorization header field is defined in IETF RFC 2617 [3] and it specifies that the usage is a scheme
followed by a value, where the value may have a structure, as is the case for the digest authentication scheme.
Security token usage in the HTTP Authorization header field was originally specified for use with OAuth and is defined
in IETF RFC 6750 [4]. Here the use of the OAuth "Bearer token" is specified so the scheme of the Authorization header
field is Bearer, following the scheme a token is placed. The token is a base64 encoded string.
Token usage in the IM PEMEA specification follows the Bearer scheme defined in IETF RFC 6750 [4].
Tokens issued by entities in the IM PEMEA architecture are expected also to be the validating entities, or to have ties to
the validating entities, consequently, whether the tokens are opaque or follow a convention such as JSON Web
Token (JWT) [i.5] is not considered relevant to usage and is not specified further.
IETF RFC 6750 [4] mandates the usage of TLS for use with Bearer tokens, this usage is further defined in clause 5.1 of
the present document.
6 Procedures and signalling
6.1 Service invocation
6.1.1 Service invocation procedures
Once the terminating PSP or PSAP has responded to the AP that it can support the PEMEA IM service then the AP
shall be capable of accepting a service invocation on the provided URI at any time. The AP shall only accept an IM
service invocation from the PIM or tPSP that sent the onCapSupportPost message.
ETSI
11 ETSI TS 103 756 V1.1.1 (2021-11)
The PSAP invokes the IM service by:
a) The call-taker initiating their willingness to chat to the PSAP Interface Module (PIM) in the PSAP or the tPSP.
b) The PIM/tPSP requesting the chat server create a chat-room.
c) The chat server creating a chat-room and return a URI to the PIM/tPSP.
d) The PIM/tPSP obtains Bearer token for the call-taker and AP.
e) The PIM/tPSP returns the URI and Bearer token to the PSAP call-taker.
f) The call-taker connects to the chat-room authenticating using the Bearer token.
g) The PIM/tPSP calling the URI provided by the AP for the IM-PEMEA service and including the URI for the
chat-room and a Bearer token in this invocation. Note that the URI is the same for the call-taker and the caller,
but the Bearer tokens are different.
h) The AP indicates to the App that the PSAP wishes to chat with the user.
i) The user indicates their willingness to chat with the PSAP to AP.
j) The AP initiates a connection to the chat-room authenticating using the Bearer token.
It is important to note that it is always the AP that authenticates to the chat room and consequently all messages from
the App shall traverse the AP. The present document only defines the protocol between the AP and other trusted entities
e.g. PSAP call-taker or First Responder, and the chat-room in the PSAP, it does not define the chat Pa messaging
between the App and the AP.
6.1.2 Service invocation object
The PIM/tPSP invokes the IM service in the AP by posting to the URI provided in the IM information element included
in the apMoreInformation contained in the EDS. The POST message includes a body containing a JSON object. The
JSON object provides the chat room URI as well as indicates how the AP should authenticate itself to the chat room.
Table 2: Invocation object fields
Element Name Presence Description
uri Mandatory The URI of the chat room.
token Mandatory A security token used to authenticate the AP to the chat room. The AP shall
include the token in the HTTP Authorization header using the Bearer token
scheme. The AP shall use the token each time it needs to establish or
re-establish a connection to the chat room for the duration of the App emergency
session.
The AP shall not provide the token to the App.
expiry Mandatory Specifies the expiry time of the security token.
expiry is an integer specifying the number of second since UTC epoch, 00:00:00
st
1 of January 1970.
Invocation example:
{
"uri": "https://chat-server.example.com/room/534wafds21s21fdf",
"token": "PPtzs5zzG5Pkf61KPz51",
"expiry": "1590563357576"
}
ETSI
12 ETSI TS 103 756 V1.1.1 (2021-11)
6.2 Chat-room creation and deletion
The chat-room is created by the chat-server under direction of the PSAP call-taker via the PIM or tPSP. When the
chat-room is created, a logging function shall be created with it to scribe all messages into and out of the chat-room.
The chat-room may also contain a chat-bot that is used to invoke services, such as translation services when required.
The chat-bot does appear as a user in the USER_LIST as its role is indicated as TRANSLATOR. This flow is shown in
Figure 1.
Figure 1: Chat initiation
Once the chat-room is created it remains active as long as the PIM or tPSP maintains a context for the EDS. When EDS
context is deleted the chat-room is also destroyed.
6.3 Chat-room creation, JOIN, and ERROR signalling
6.3.1 Semantics
The figure in the following sub clauses show the signalling involved in establishing and subsequently joining a PEMEA
chat session. By necessity the diagrams show four distinctive types of signalling:
• Semantic signalling across the Pa interface between the App and the AP is explicitly not defined in PEMEA.
So, while the message names and contents may not align with any specific implementation, the semantics of
what the messages convey should be understood.
• Core PEMEA signalling are explicit messages defined in the PEMEA technical specification ETSI
TS 103 478 [1].
• Chat semantic signalling is messaging that needs to occur between the PSAP call-taker equipment, the
PIM/tPSP and the software entities and components required to establish the chat service. These messages are
intended to provide an idea of what needs to occur, not how it should be implement. Consequently, they are
informative only and not normative.
• IM (chat) normative signalling messages and semantics explicitly defined in the present document.
ETSI
13 ETSI TS 103 756 V1.1.1 (2021-11)
6.3.2 IM service invocation
Figure 2: IM service invocation
1) App initiates and emergency session with the AP over the Pa interface indicating that it can support the Instant
messaging.
2) The AP creates an EDS message from the data provided by the App and includes the PEMEA instant
messaging protocol capability. The AP then sends the EDS into the PEMEA network.
3) The EDS arrives at the PIM/tPSP. The PIM supports the PEMEA IM capability and includes this option in the
onCapupportPost back to the AP.
4) The AP binds the emergency session to the PIM that sent the onCapSupportPost message and then signals to
the App over the Pa interface that the PSAP can support the PEMEA IM functionality.
5) The PIM notifies the PSAP-CPE that a new EDS has arrived.
6) The PSAP call-taker via the PSAP-CPE requests the capabilities agreed with the AP, sees the PEMEA IM
capability and request the PIM to initiate the creation of a chat-room.
The PIM request that the chat server create a chat-room
The chat server creates a chat-room which in turn creates a chat-log.
7) The chat-room returns its URI to the chat server.
The chat server returns the chat-room URI to the PIM.
The PIM obtains Bearer tokens for the call-taker and the AP.
The PIM returns the chat-room URI and a Bearer token and its expiry time to the call-taker via the PSAP-CPE.
8) The PIM invokes the PEMEA IM capability in the AP using the URI provided in the capability sent in the
EDS. The PIM includes the chat-room URI, a Bearer token and its expiry time in the body of the HTTP POST
used to invoke the capability in the AP.
9) The AP signals to the App over the Pa interface that the PSAP has invoked the instant message capability.
ETSI
14 ETSI TS 103 756 V1.1.1 (2021-11)
6.3.3 JOIN message flow
Figure 3: IM JOIN flow
Once the IM service has been invoked in the AP, then the PSAP call-taker and Caller join the chat-room:
1) The PSAP call-taker joins the chat-room.
2) The chat-room writes a log to the chat-log indicating that the PSAP has joined the chat-room.
3) The chat-room responds to the PSAP with the current USER_LIST, which only contains the PSAP.
4) The App signals to the AP over the Pa interface that it wishes to join the chat.
5) The AP connects to the chat-room and is authenticated using the token and the connection is promoted to a
websocket.
The AP then sends a JOIN message to the chat-room indicating that the connecting entity username and that
the role is a CALLER. The combination of username and role shall be unique for the room.
6) The chat-room accepts the JOIN message and writes it to the chat-log.
7) The chat-room then sends a USER_LIST message to both the PSAP and the AP containing the PSAP and
CALLER information.
8) The AP relays the USER_LIST to the App over the Pa interface.
6.3.4 ERROR message flow
The error message is sent from the chat-room to a participant in two circumstance:
1) When the username and role received in a JOIN message are already in use by an active user in the chat-room.
In this case, the user of the App is informed by the AP and selects a new username before attempting to re-join
the room.
ETSI
15 ETSI TS 103 756 V1.1.1 (2021-11)
2) The message received by the chat-room is not understood or is badly formed. The AP should notify the App
that the message could not be delivered. This condition allows the App to take actions, but it cannot be
rectified by the user. The AP shall discard the erroneous message. The App shall not attempt to resend the
same message.
Figure 4: ERROR message flow
The PSAP are and the caller have already joined the chat room:
1) PSAP feels the need to invite to Medical first responders to the chat to assist with the call. How this happens is
a matter of implementation but the first responder terminals need to receive the room URI as well as access
security tokens.
2) MED-1 receives the invitation and sends a JOIN message to the chat-room indicating that his name is John and
that he has the role of MED.
3) The chat-room receives this information logs it and sends the updated USER_LIST including John the MED's
details to the Caller, the PSAP and to John.
4) MED-2 receives the invitation and sends a JOIN message to the chat-room indicating that his name is John and
that he has the role of MED.
5) Since MED-1 is called John and is already active in the room, the chat-room sends an ERROR message to
John MED-2 indicating that his username is a duplicate.
ETSI
16 ETSI TS 103 756 V1.1.1 (2021-11)
6.4 TEXT_MESSAGE flow
Figure 5: TEXT_MESSAGE signalling flow
Once the AP has joined the chat-room it is able to send text messages to the other participants in the room:
1) The App user sends the test message (e.g. "Help Me") to the AP over the Pa interface.
2) The AP takes the user's message and creates a TEXT_MESSAGE for transmission to the chat-room and sends
the TEXT_MESSAGE to the chat-room.
3) The chat-room receives the message and writes it to the chat-log.
4) The chat-room adds a unique chat-room message id to the message, along with the room identifier and a time
stamp and sends this to the chat-log.
5) The chat-room sends the new TEXT_MESSAGE to the PSAP call-taker.
6) The chat-room sends the new TEXT_MESSAGE to the AP.
7) The AP relays the message to the App, indicating its message is now in the chat-room.
6.5 REPLY message signalling
The REPLY message allows a user to respond to a specific message. This ensures that the context of the response is
maintained in the event that subsequent text messages have been exchanged. A REPLY may be sent in reference to a
TEXT_MESSAGE or another REPLY message.
The REPLY message is similar to the TEXT_MESSAGE but includes a reference to the unique identifier of the
message to which it is replying. The flow follows the TEXT_MESSAGE flow described in clause 6.4.
ETSI
17 ETSI TS 103 756 V1.1.1 (2021-11)

Figure 6: PEMEA IM REPLY message signalling flow
1) Caller has the AP send a TEXT_MESSAGE (e.g. with the message "help me") to the chat-room, and the chat-
room adds its id and time stamp to the message before sending it out to the AP and the PSAP.
2) The PSAP call-taker types a reply to the message asking what the matter is. The REPLY message from the
PSAP includes a reference to the original TEXT_MESSAGE.
3) The chat-room logs the incoming message from the PSAP.
4) The chat-room appends a new message-id, room identifier and timestamp to the REPLY message and sends
this to the chat-log.
5) The chat-room sends the new REPLY message to the AP.
6) The chat-room sends the new REPLY message to the PSAP call-taker.
6.6 Message translations and signalling
6.6.1 Overview of the translation functionality
Language translation is an optional function of the chat-room. However, support of the capability is recommended
given the primary function of PEMEA is to support application roaming which may result in the call-taker and caller
conversing in different languages. IM functions in the AP shall accept any translation messages but may choose to
ignore them.
Message translations are controlled by the chat-room. It maintains a list of languages that are used by chat-room
participants. It generates this list from the languages provided in the JOIN messages for each participant (see
clause 6.3.3). The list will always have at least one language in it.
When the chat-room receives a TEXT_MESSAGE or a REPLY message, it invokes a third-party translation service
requesting a translation for the message into each of the languages maintained in the chat-room's supported languages
list. The text translations are then returned to the chat-room for sending to the room participants and the chat-log.
The general flow for the above is shown in Figure 7, with the invocation from clause 6.1 having already been
performed.
ETSI
18 ETSI TS 103 756 V1.1.1 (2021-11)

Figure 7: PEMEA IM message translation
1) The PSAP call-taker joins the chat-room and indicates that they would like to converse in English.
The chat-room adds English to its list of languages in use.
The chat-room writes to the chat-log that the PSAP call-taker has joined the room.
The chat-room sends a USER_LIST message to the PSAP call-taker consisting only of the PSAP.
2) The AP sends a JOIN message to the chat-room with the role of CALLER and indicates that the user wishes to
converse in French.
3) The chat-room adds French to its list of languages in use.
The chat-room writes to the chat-log that the caller has joined the chat-room.
The chat-room sends USER_LIST messages to both the AP and the PSAP call-taker. The message contains the
caller and call-taker information.
4) The App user sends a message in French saying " j'ai besoin d'aide" to the AP over the Pa interface.
The AP creates a TEXT_MESSAGE packet, with the text sent by the user and indicates that the message is
written in French.
The AP then sends the TEXT_MESSAGE to the chat-room.
5) The chat-room writes the TEXT_MESSAGE to the chat-log.
The chat-room adds the unique id, room id and timestamp to the TEXT_MESSAGE and writes the new
message to the chat-log.
6) The chat-room sends the new TEXT_MESSAGE to the AP and the call-taker.
7) The chat-room invokes a third-party translation service, sending the users' message in French and requesting it
be translated into all other languages that the chat-room has in its list of in-use languages, in this case only
English.
The translation server returns the English translation for " j'ai besoin d'aide", which is "help me".
ETSI
19 ETSI TS 103 756 V1.1.1 (2021-11)
8) The chat-room takes the translations and creates a TRANSLATION message.
The TRANSLATION message contains a unique message id, a reference to the TEXT_MESSAGE or REPLY
message, a timestamp, and all of the translations.
The chat-room sends the TRANSLATION message to the chat-log.
9) The chat-room sends the TRANSLATION message to the AP and the PSAP call-taker.
The reference field allows the end-points to link the translated message back to the source message. This enables the
user to display the originally provided text if the translation does not appear to make sense.
6.6.2 TEXT_MESSAGE translation example
Suppose that there are three languages in use in the chat-room, English (en), Spanish (es) and French (fr), and it
received the following TEXT_MESSAGE:
{
"id":"5dd2bd8ba5568000079fa11c",
"type":"TEXT_MESSAGE",
"message":{
"language":"es",
"text":"hola"
},
"room":"ttRRkzORz",
"user":{
"name":"PSAP-XqwFbQ-A",
"role":"PSAP"
},
"timestamp":1574092171988
}
The chat-room would request from its translation service that the message be translated from Spanish (es) to English
(en) and French (fr). Once it got back the translations it would construct the following TRANSLATION message, write
it to the chat-log and return it to the room participants.
{
"type":"TRANSLATION",
"reference":"5dd2bd8ba5568000079fa11c",
"translations":[
{
"language":"en",
"text":"hello"
},
{
"language":"fr",
"text":"bonjour"
}
]
}
The chat-server will echo to all the participants in
...