|
TECHNICAL SPECIFICATION
Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS);
LTE;
Communication HOLD (HOLD) using IP Multimedia (IM)
Core Network (CN) subsystem;
Protocol specification
(3GPP TS 24.610 version 15.1.0 Release 15)
---------------------- Page: 1 ----------------------
3GPP TS 24.610 version 15.1.0 Release 15 1 ETSI TS 124 610 V15.1.0 (2018-07)
Reference
RTS/TSGC-0124610vf10
Keywords
GSM,LTE,UMTS
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:
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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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
If you find errors in the present document, please send your comment to one of the following services:
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 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3GPP TS 24.610 version 15.1.0 Release 15 2 ETSI TS 124 610 V15.1.0 (2018-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
.
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
---------------------- Page: 3 ----------------------
3GPP TS 24.610 version 15.1.0 Release 15 3 ETSI TS 124 610 V15.1.0 (2018-07)
Contents
Intellectual Property Rights . 2
Foreword . 2
Modal verbs terminology . 2
Foreword . 5
1 Scope . 6
2 References . 6
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Communication Hold (HOLD) . 7
4.1 Void . 7
4.2 Description . 7
4.2.1 General description . 7
4.3 Operational requirements . 7
4.3.1 Provision/withdrawal . 7
4.3.2 Requirements on the originating network side. 7
4.3.3 Requirements in the network . 7
4.3.4 Requirements on the terminating network side . 7
4.4 Coding requirements . 7
4.5 Signalling requirements . 7
4.5.1 Activation/deactivation . 7
4.5.2 Invocation and operation . 8
4.5.2.1 Actions at the invoking UE . 8
4.5.2.2 Void. 9
4.5.2.3 Void. 9
4.5.2.4 Actions at the AS of the invoking UE . 9
4.5.2.4.1 General . 9
4.5.2.4.2 Bandwidth management . 9
4.5.2.4.3 Announcements . 9
4.5.2.4.4 Resource sharing . 9
4.5.2.5 Void. 10
4.5.2.6 Void. 10
4.5.2.7 Void. 10
4.5.2.8 Void. 10
4.5.2.9 Actions at the held UE . 10
4.6 Interaction with other services . 10
4.6.1 Communication Hold (HOLD) . 10
4.6.2 Terminating Identification Presentation (TIP) . 10
4.6.3 Terminating Identification Restriction (TIR) . 10
4.6.4 Originating Identification Presentation (OIP) . 10
4.6.5 Originating identification restriction (OIR) . 10
4.6.6 Conference calling (CONF) . 10
4.6.7 Communication DIVersion services (CDIV) . 11
4.6.8 Malicious Communication IDentification (MCID) . 11
4.6.9 Anonymous Communication Rejection and Communication Barring (ACR/CB) . 11
4.6.10 Explicit Communication Transfer (ECT) . 11
4.6.11 Enhanced Calling Name (eCNAM) . 11
4.7 Interactions with other networks . 11
4.7.1 Void . 11
4.7.2 Void . 11
4.7.3 Void . 11
4.8 Parameter values (timers) . 11
Annex A (informative): Signalling Flows . 12
ETSI
---------------------- Page: 4 ----------------------
3GPP TS 24.610 version 15.1.0 Release 15 4 ETSI TS 124 610 V15.1.0 (2018-07)
A.1 HOLD communication . 12
A.1.1 HOLD communication without announcement . 12
A.1.2 HOLD communication with announcement . 14
A.1.3 HOLD communication with modification of the SDP answer . 16
A.2 RESUME Communication . 18
A.2.1 RESUME communication without announcement . 18
A.2.2 RESUME communication with announcement . 21
Annex B (informative): Example of filter criteria . 24
Annex C (informative): Change history . 25
History . 26
ETSI
---------------------- Page: 5 ----------------------
3GPP TS 24.610 version 15.1.0 Release 15 5 ETSI TS 124 610 V15.1.0 (2018-07)
Foreword
This Technical Specification (TS) was been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN) and originally published as
rd
ETSI TS 183 010 [7]. It was transferred to the 3 Generation Partnership Project (3GPP) in December 2007.
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
---------------------- Page: 6 ----------------------
3GPP TS 24.610 version 15.1.0 Release 15 6 ETSI TS 124 610 V15.1.0 (2018-07)
1 Scope
The present document specifies the stage three Protocol Description of the Communication Hold (HOLD) services,
based on stages one and two of the ISDN Hold (HOLD) supplementary services. It provides the protocol details in the
IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) and the Session
Description Protocol (SDP).
The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to
support the HOLD supplementary service.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
[2] Void.
[3] Void
[4] IETF RFC 3264 (2002): "An Offer/Answer Model with the Session Description Protocol (SDP)".
[5] 3GPP TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service
and supplementary services; Stage 1".
[6] 3GPP TS 24.628: "Common Basic Communication procedures; Protocol specification".
[7] ETSI TS 183 010 V1.2.2: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Signalling Control Protocol; Communication HOLD
(HOLD) PSTN/ISDN simulation services; Protocol specification".
[8] IETF RFC 7090 (April 2014): "Public Safety Answering Point (PSAP) Callback".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TS 22.173 [5] apply.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACR/CB Anonymous Communication Rejection and Communication Barring
AS SIP Application Server
CDIV Communication DIVersion
CSCF Call Session Control Function
ECT Explicit Communication Transfer
HOLD communication session HOLD
IMS IP Multimedia Subsystem
ETSI
---------------------- Page: 7 ----------------------
3GPP TS 24.610 version 15.1.0 Release 15 7 ETSI TS 124 610 V15.1.0 (2018-07)
IP Internet Protocol
ISDN Integrated Service Digital Network
MCID Malicious Communication IDentification
OIP Originating Identification Presentation
OIR Originating Identification Restriction
P-CSCF Proxy-CSCF
PSAP Public Safety Answering Point
PSTN Public Switched Telephone Network
S-CSCF Serving-CSCF
SDP Session Description Protocol
SIP Session Initiation Protocol
TIP Terminating Identification Presentation
TIR Terminating Identification Restriction
UE User Equipment
4 Communication Hold (HOLD)
4.1 Void
4.2 Description
4.2.1 General description
The Communication Hold supplementary service enables a user to suspend the reception of media stream(s) of an
established IP multimedia session, and resume the media stream(s) at a later time.
4.3 Operational requirements
4.3.1 Provision/withdrawal
The HOLD service that includes announcements shall be provided after prior arrangement with the service provider.
4.3.2 Requirements on the originating network side
No specific requirements are needed in the network.
4.3.3 Requirements in the network
No specific requirements are needed in the network.
4.3.4 Requirements on the terminating network side
No specific requirements are needed in the network.
4.4 Coding requirements
No specific coding requirements are needed.
4.5 Signalling requirements
4.5.1 Activation/deactivation
The HOLD service is activated at provisioning and deactivated at withdrawal.
4.5.1A Registration/erasure
The HOLD service requires no registration. Erasure is not applicable.
ETSI
---------------------- Page: 8 ----------------------
3GPP TS 24.610 version 15.1.0 Release 15 8 ETSI TS 124 610 V15.1.0 (2018-07)
4.5.1B Interrogation
Interrogation of HOLD is not applicable.
4.5.2 Invocation and operation
4.5.2.1 Actions at the invoking UE
In addition to the application of procedures according to 3GPP TS 24.229 [1], the following procedures shall be applied
at the invoking UE in accordance with RFC 3264 [4].
A UE shall not invoke the HOLD service on a dialog associated with an emergency call the UE has initiated.
If not all the media streams are affected, the invoking UE shall generate a new SDP offer where:
1) for each media stream that is to be held, the SDP offer contains:
- an "inactive" SDP attribute if the stream was previously set to "recvonly"; or
- a "sendonly" SDP attribute if the stream was previously set to "sendrecv";
NOTE 1: If the directionality attribute of the media stream is currently "sendonly" or "inactive", then that media
stream is not put on hold and, in the SDP offer, the directionality for that media stream remains
unchanged.
2) for each held media stream that is to be resumed, the SDP offer contains:
- a "recvonly" SDP attribute if the stream was previously an inactive media stream; or
- a "sendrecv" SDP attribute if the stream was previously a sendonly media stream, or the attribute may be
omitted, since sendrecv is the default; and
3) for each media stream that is unaffected, the media parameters in the SDP offer remain unchanged from the
previous SDP.
If all the media streams are to be held:
- if they all have identical directionality, the invoking UE shall generate an SDP offer containing a session level
direction attribute, or separate media level direction attributes, in the SDP that is set to:
1) "inactive" if the streams were previously set to "recvonly"; or
2) "sendonly" if the streams were previously set to "sendrecv"; and
NOTE 2: If the directionality attribute of all the media streams is currently "sendonly" or "inactive", then all these
media streams are not put on hold and, in the SDP offer, the directionality for these media streams will
remain unchanged.
- if they all do not have identical directionality, then for each media stream in the session, the invoking UE shall
follow the procedure listed above for individual media streams.
If all the media streams were previously on hold and are to be resumed:
- if they all have identical directionality, the invoking UE shall generate a session level direction attribute, or
separate media level direction attributes, in the SDP that is set to:
1) "recvonly" if the streams were previously inactive media streams; or
2) "sendrecv" if the streams were previously sendonly media streams, or the attribute may be omitted, since
sendrecv is the default; and
- if they all do not have identical directionality, then for each media stream in the session, the invoking UE shall
follow the procedure listed above for individual media streams.
If, in the generated SDP offer, there is at least one media stream whose directionality has changed from the previous
SDP, the UE shall send the generated SDP offer in a re-INVITE request (or UPDATE request) to the remote UE.
ETSI
---------------------- Page: 9 ----------------------
3GPP TS 24.610 version 15.1.0 Release 15 9 ETSI TS 124 610 V15.1.0 (2018-07)
4.5.2.2 Void
4.5.2.3 Void
4.5.2.4 Actions at the AS of the invoking UE
4.5.2.4.1 General
The AS shall based on local policy on how to handle PSAP callbacks reject any HOLD invocation request from the
served UE by sending a 403 (Forbidden) response.
The mechanism to identify an INVITE request as a PSAP callback depends on local policy and can be based on the
PSAP callback indicator specified in IETF RFC 7090 [8].
4.5.2.4.2 Bandwidth management
As a network option, for each media stream marked "recvonly" in the SDP answer sent to the invoking UE, the AS of
the invoking UE shall lower the bandwidth by setting the "b=AS:" parameter to a small value, e.g. "b=AS:0". The
"b=RR:" and "b=RS:" parameters shall be set to values large enough to enable continuation of the RTCP flow, e.g.
"b=RR:800" and "b=RS:800".
As a network option, for each media stream marked "inactive" in the SDP answer sent to the invoking UE, the AS of the
invoking UE shall lower the bandwidth by setting the "b=AS:" parameter to a small value, e.g. "b=AS:0". The "b=RR:"
and "b=RS:" parameters shall be set to values large enough to enable continuation of the RTCP flow, e.g. "b=RR:800"
and "b=RS:800".
NOTE: A media stream in the SDP answer can be marked as "recvonly" at media description level or/and at
session description level (i.e. all the media streams are marked "recvonly").
4.5.2.4.3 Announcements
As a network option, the AS of the invoking UE shall initiate the procedures for the provision of an announcement to
the held user in accordance with 3GPP TS 24.628 [6]. An announcement is only possible on the media stream that is in
sendonly state on the AS after the signalling exchange for HOLD.
NOTE 1: Not providing an announcement allows the service provider to provide the possibility to change from
bidirectional to unidirectional media streams.
NOTE 2: A service provider can decide to provide announcements only if a pre-defined set of media streams are
put on HOLD.
4.5.2.4.4 Resource sharing
A precondition for the procedures in this subclause are that the AS:
1) supports resource sharing;
2) knows that the P-CSCF supports resource sharing; and
NOTE 1: The AS can know that the P-CSCF supports resource sharing based on information in the MIME body in
rd
a 3 party REGISTER request or by means outside the scope of the present document.
3) applied the procedures in 3GPP TS 24.229 [1], subclause 5.7.1.20 when the first session to or from the served
UE was established.
NOTE 2: The resource sharing procedures related to the HOLD service do not need to use the "resource-sharing-
key-list" parameter.
For a session that is identified as an emergency session the AS shall not insert the Resource-Share header field.
When the AS receives a response to a HOLD request from the served UE the AS stores
- the sharing keys; and
- the m-lines in the HOLD response, along with an indication that the m-line is on HOLD.
ETSI
---------------------- Page: 10 ----------------------
3GPP TS 24.610 version 15.1.0 Release 15 10 ETSI TS 124 610 V15.1.0 (2018-07)
When the AS receives an SDP answer in a response towards the served UE for an initial originating INVITE from the
served UE the AS compares the SDP answer in the received response with any stored SDP for a session involving the
same UE. If the m-lines in the stored SDP and the received SDP answer match, then for each held m-line in the stored
SDP, the AS associates the sharing-key from the held m-line to the corresponding m-line in the received SDP response.
Before forwarding the SDP answer in the INVITE response the AS inserts a Resource-Share header field using these
associated sharing-keys for the matching m-lines and indicates in the "rules" parameter the directionality to be "UL-DL"
and produces new unique sharing keys for the other m-lines.
When the AS receives a HOLD response towards the served UE, and there is an incoming session in alerting phase for
which the AS has associated unique resource sharing keys, the AS compares the SDP in the HOLD response and the
previously stored SDP and if they match, the AS associates to the held lines in the HOLD response the sharing keys
from the stored m-lines. Before forwarding the HOLD response the AS inserts a Resource-Share header field using
these associated sharing-keys for the matching m-lines and indicates in the "rules" parameter the directionality to be
"UL-DL" and produces new unique sharing keys for the other m-lines.
When the AS receives a response from the remote UE to a RESUME request for an m-line where there exists an active
m-line in another session, the AS shall apply a new unique sharing key to that m-line or set the Resource-Share header
field to the value "no-media-sharing".
4.5.2.5 Void
4.5.2.6 Void
4.5.2.7 Void
4.5.2.8 Void
4.5.2.9 Actions at the held UE
3GPP TS 24.229 [1] shall apply.
NOTE: If the media stream is not held by the local UE, the media stream has been held by the remote UE and no
media are received, then the UE is expected to render a communication held indication.
4.6 Interaction with other services
4.6.1 Communication Hold (HOLD)
Not applicable.
4.6.2 Terminating Identification Presentation (TIP)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.3 Terminating Identification Restriction (TIR)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.4 Originating Identification Presentation (OIP)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.5 Originating identification restriction (OIR)
No impact, i.e. neither service shall affect the operation of the other service.
4.6.6 Conference calling (CONF)
If a participant of a conference invokes the HOLD service, it is not desirable to provide an announcement to the
conference. If the AS supporting the HOLD supplementary service receives a re-INVITE (or UPDATE) request on a
...