3GPP TS 24.371: Technical Specification

3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals;

3GPP TS 24.371
Web Real-Time Communications (WebRTC) access to
V12.12.0
IP Multimedia (IM) Core Network (CN) subsystem
the
(2021-03)
(IMS);
Technical Specification
Stage 3;
Protocol specification
(Release 12)
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP..
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this
Specification.
Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 12 2 3GPP TS 24.371 V12.12.0 (2021-03)
Keywords
IMS, IP, Web Real Time Communication
3GPP
Postal address
3GPP support office address

650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org
Copyright Notification
No part may be reproduced except as authorized by written permission.

The copyright and the foregoing restriction extend to reproduction in all media.
© 2021, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.
UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association
3GPP
Release 12 3 3GPP TS 24.371 V12.12.0 (2021-03)
Contents
Foreword..........................................................................................................................................................6
1 Scope......................................................................................................................................................7
2 References..............................................................................................................................................7
3 Definitions and abbreviations.................................................................................................................9
3.1 Definitions...........................................................................................................................................................9
3.2 Abbreviations.......................................................................................................................................................9
4 Overview of WebRTC access to IMS.....................................................................................................9
4.1 General.................................................................................................................................................................9
5 Functional entities................................................................................................................................10
5.1 General...............................................................................................................................................................10
5.2 WIC (WebRTC IMS Client)..............................................................................................................................10
5.3 WWSF (WebRTC Web Server Function).........................................................................................................10
5.4 WAF (WebRTC Authorisation Function).........................................................................................................10
5.5 eP-CSCF (P-CSCF enhanced for WebRTC).....................................................................................................10
5.6 eIMS-AGW (IMS Access Gateway enhanced for WebRTC)...........................................................................11
5A Data transport.......................................................................................................................................11
5A.1 General...............................................................................................................................................................11
5A.2 UE......................................................................................................................................................................11
5A.3 WWSF (WebRTC Web Server Function).........................................................................................................11
5A.4 eP-CSCF (P-CSCF enhanced for WebRTC).....................................................................................................11
5B Data framing and securing....................................................................................................................12
5B.1 General...............................................................................................................................................................12
5B.2 UE......................................................................................................................................................................12
5B.3 WWSF (WebRTC Web Server Function).........................................................................................................12
5B.4 eP-CSCF (P-CSCF enhanced for WebRTC).....................................................................................................12
5C Data formats.........................................................................................................................................12
5C.1 General...............................................................................................................................................................12
5C.2 UE......................................................................................................................................................................12
5C.3 WWSF (WebRTC Web Server Function).........................................................................................................13
5C.4 eP-CSCF (P-CSCF enhanced for WebRTC).....................................................................................................13
5D Connection management......................................................................................................................13
5D.1 General...............................................................................................................................................................13
5D.2 UE......................................................................................................................................................................13
5D.3 WWSF (WebRTC Web Server Function).........................................................................................................13
5D.4 eP-CSCF (P-CSCF enhanced for WebRTC).....................................................................................................14
5E Presentation and control.......................................................................................................................14
5E.1 General...............................................................................................................................................................14
5E.2 UE......................................................................................................................................................................14
5E.3 WWSF (WebRTC Web Server Function).........................................................................................................14
5E.4 eP-CSCF (P-CSCF enhanced for WebRTC).....................................................................................................14
5F Local system support functions............................................................................................................14
5F.1 General...............................................................................................................................................................14
5F.2 UE......................................................................................................................................................................14
5F.3 WWSF (WebRTC Web Server Function).........................................................................................................14
5F.4 eP-CSCF (P-CSCF enhanced for WebRTC).....................................................................................................15
6 Registration and authentication............................................................................................................15
6.1 General...............................................................................................................................................................15
6.2.1 WIC registration of individual Public User Identity using IMS authentication..........................................15
3GPP
Release 12 4 3GPP TS 24.371 V12.12.0 (2021-03)
6.2.1.1 General...................................................................................................................................................15
6.2.1.2 W2 using SIP Digest credentials............................................................................................................16
6.2.1.3 W2 using IMS-AKA..............................................................................................................................16
6.2.2 WIC registration of individual public user identity based on web authentication.......................................16
6.2.3 WIC registration of individual public user identity from a pool of public user identities...........................16
6.3 WWSF (WebRTC Web Server Function) and WAF (WebRTC Authorisation Function)...............................17
6.3.1 WIC registration of individual public user identity using web credentials..................................................17
6.4.1 WIC registration of individual Public User Identity using IMS authentication..........................................17
6.4.1.1 Determination of IMS authentication mechanism..................................................................................17
6.4.1.2 W2 using SIP Digest credentials............................................................................................................17
6.4.1.3 W2 using IMS-AKA..............................................................................................................................18
6.4.2 WIC registration of individual public user identity using web credentials..................................................18
6A Deregistration.......................................................................................................................................19
6A.1 General...............................................................................................................................................................19
6A.2 WIC (WebRTC IMS Client)..............................................................................................................................20
6A.3 eP-CSCF (P-CSCF enhanced for WebRTC).....................................................................................................20
7 Call origination and termination...........................................................................................................20
7.1 General...............................................................................................................................................................20
7.2.1 General.........................................................................................................................................................20
7.2.2 WIC originating call.....................................................................................................................................20
7.2.3 WIC terminating call....................................................................................................................................21
7.2.4 WIC emergency call.....................................................................................................................................21
7.4.1 General.........................................................................................................................................................22
7.4.4 WIC emergency call.....................................................................................................................................23
8 Data channel open and close.................................................................................................................24
8.1 General...............................................................................................................................................................24
8.2.1 General.........................................................................................................................................................24
8.4.1 General.........................................................................................................................................................25
9 Call modification..................................................................................................................................26
10 IP multimedia application support in the IM CN subsystem using webRTC........................................26
10.1 General...............................................................................................................................................................26
10.2 Access to MMTel and supplementary services using webRTC........................................................................26
10.2.1 General.........................................................................................................................................................26
10.2.2 WIC (WebRTC IMS Client)........................................................................................................................26
10.2.2.1 SIP based protocol used by the WIC......................................................................................................26
10.2.2.2 non-SIP based protocol used by the WIC..............................................................................................26
10.2.3 WWSF (WebRTC Web Server Function)...................................................................................................27
10.2.4 eP-CSCF (P-CSCF enhanced for WebRTC)...............................................................................................27
3GPP
Release 12 5 3GPP TS 24.371 V12.12.0 (2021-03)
Annex A (informative): Example signalling flows......................................................................................28

A.1 Scope of signalling flows......................................................................................................................28
A.2 Void......................................................................................................................................................28
A.3 Signalling flows for registration...........................................................................................................28
A.3.1 Void...................................................................................................................................................................28
A.3.2 WIC registration of individual public user identity based on web authentication............................................28
A.3.3 Void...................................................................................................................................................................30
A.4 Void......................................................................................................................................................30
A.5 Void......................................................................................................................................................30
Annex B (informative): Change history..........................................................................................................31
3GPP
Release 12 6 3GPP TS 24.371 V12.12.0 (2021-03)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
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.
3GPP
Release 12 7 3GPP TS 24.371 V12.12.0 (2021-03)
1 Scope
The present document provides the details for allowing Web Real-Time Communication (WebRTC) IMS Clients (WIC)
to access the IP Multimedia (IM) Core Network (CN) subsystem.
The present document is applicable to WebRTC IMS client (WIC), eP-CSCF, eIMS-AGW, WebRTC Web Server
Function (WWSF) and WebRTC Authorization Function (WAF).
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 TR 21.905: "Vocabulary for 3GPP Specifications".
[2] IETF RFC 7118: "The WebSocket Protocol as a Transport for the Session Initiation Protocol
(SIP)".
[3] 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP)
and Session Description Protocol (SDP); Stage 3".
[4] 3GPP TS 23.228: " IP Multimedia Subsystem (IMS); Stage 2".
[5] IETF RFC 5763: "Framework for Establishing a Secure Real-time Transport Protocol (SRTP)
Security Context Using Datagram Transport Layer Security (DTLS)".
[6] IETF RFC 5764: "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the
Secure Real-time Transport Protocol (SRTP)".
[7] 3GPP TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service
and supplementary services; Stage 1".
[8] 3GPP TS 24.173: "IMS multimedia telephony communication service and supplementary services;
Stage 3".
[9] 3GPP TS 33.203: "Access security for IP based services".
[10] RFC 6750 (October 2012): "The OAuth 2.0 Authorization Framework: Bearer Token Usage".
[11] 3GPP TS 23.292: "IP Multimedia Subsystem (IMS) Centralized Services; Stage 2".
[12] RFC 5009 (September 2007): "Private Header (P-Header) Extension to the Session Initiation
Protocol (SIP) for Authorization of Early Media".
[13] 3GPP TS 23.334: "IMS Application Level Gateway (IMS-ALG) – IMS Access Gateway (IMS-
AGW) interface".
[14] RFC 4145 (September 2005): "TCP-Based Media Transport in the Session Description Protocol
(SDP)".
3GPP
Release 12 8 3GPP TS 24.371 V12.12.0 (2021-03)
[15] RFC 4572 (July 2006): "Connection-Oriented Media Transport over the Transport Layer Security
(TLS) Protocol in the Session Description Protocol (SDP)".
[16] RFC 8831 (January 2021): "WebRTC Data Channels".
[17] RFC 8832 (January 2021): "WebRTC Data Channel Establishment Protocol".
[18] RFC 8841 (January 2021): "Stream Control Transmission Protocol (SCTP)-Based Media

Transport in the Session Description Protocol (SDP)".
[19] RFC 3261 (June 2002): "SIP: Session Initiation Protocol".
[20] RFC 3264 (June 2002): "An Offer/Answer Model with the Session Description Protocol (SDP)".
[21] RFC 7675 (October 2015): "STUN Usage for Consent Freshness".
[22] RFC 5245 (April 2010): "Interactive Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal for Offer/Answer Protocols".
[23] RFC 8261 (November 2017): "Datagram Transport Layer Security (DTLS) Encapsulation of

SCTP Packets".[24] RFC 6455 (December 2011): "The WebSocket Protocol".
[25] RFC 8843 (January 2021): "Negotiating Media Multiplexing Using the Session Description
Protocol (SDP)".
[26] RFC 3581 (August 2003): "An Extension to the Session Initiation Protocol (SIP) for Symmetric
Response Routing".
[27] RFC 8898 (September 2020): "Third-Party Token-Based Authentication and Authorization for

Session Initiation Protocol (SIP)".
[28] RFC 6544 (March 2012): "TCP Candidates with Interactive Connectivity Establishment (ICE)".
[29] Void.
[30] RFC 8825 (January 2021): "Overview: Real-Time Protocols for Brower-Based Applications".
[31] Void.
[32] RFC 3310 (September 2002): "Hypertext Transfer Protocol (HTTP) Digest Authentication Using
Authentication and Key Agreement (AKA)".
[33] RFC 4169 (November 2005): "Hypertext Transfer Protocol (HTTP) Digest Authentication Using
Authentication and Key Agreement (AKA) Version-2".
[34] 3GPP TS 26.114: "IP multimedia subsystem (IMS); Multimedia telephony, Media handling and
interaction".
[35] RFC 7519 (May 2015): "JSON Web Token (JWT)".
[36] Void.
[37] Void.
[38] RFC 5761 (April 2010): "Multiplexing RTP Data and Control Packets on a Single Port".
[39] RFC 8838 (January 2021): "Trickle ICE: Incremental Provisioning of Candidates for the
Interactive Connectivity Establishment (ICE) Protocol".
[40] RFC 5766 (April 2010): "Traversal Using Relays around NAT (TURN): Relay Extensions to
Session Traversal Utilities for NAT (STUN)".
3GPP
Release 12 9 3GPP TS 24.371 V12.12.0 (2021-03)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in
3GPP TR 21.905 [1].
For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [4] annex U
apply:
P-CSCF enhanced for WebRTC (eP-CSCF)

WebRTC Authorization Function (WAF)
WebRTC IMS Client (WIC)
WebRTC Web Server Function (WWSF)
For the purposes of the present document, the following terms and definitions given in RFC 5245 [22] apply:
ICE Lite
Full ICE
Host ICE candidates
For the purposes of the present document, the following terms and definitions given in RFC 8825 [30] apply:
WebRTC endpoint
WebRTC non-browser
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
3GPP TR 21.905 [1].
CN Core Network
CSCF Call Session Control Function
eP-CSCF enhanced Proxy CSCF
IM IP Multimedia
IP Internet Protocol
WAF WebRTC Authorization Function
WebRTC Web Real-Time Communication
WWSF WebRTC Web Server Function
4 Overview of WebRTC access to IMS
4.1 General
The relationship between functional entities for the interface at the W1 reference point, between the WWSF and the UE,
the interface at the W2 reference point, between the eP-CSCF and the UE, the interface at the W3 reference point,
between the UE and the eIMS-AGW, and the interface at the W4 reference point, between the WWSF and the WAF,
are defined in annex U of 3GPP TS 23.228 [4].
The relationship between the functional entities for interface at the Mw reference point, between the eP-CSCF and the
remainder of the IP multimedia core network subsystem, is defined in 3GPP TS 23.228 [4].
A number of appropriate mechanisms exist for signalling communication between the WIC and the eP-CSCF. Sucessful
use of a mechanism other than those specified in this document will require some form of prior agreement between the
operator of the WWSF and the operator of the eP-CSCF, as to the nature of the signalling mechanism that is to be
3GPP
Release 12 10 3GPP TS 24.371 V12.12.0 (2021-03)
adopted, and therefore the interworking required at the eP-CSCF. The mechanism of prior agreement and the nature of
such agreement is not defined in this document.
A signalling transport mechanism for SIP is standardised in this release of this document, i.e. SIP over websockets (see
RFC 7118 [2]), but this is not a mechanism that has to be supported by all eP-CSCFs.
When SIP over websockets is used, it can be appropriate for the SIP used to conform to the definitions for SIP on the
Gm reference point as specified in 3GPP TS 24.229 [3]. Such a requirement is not mandatory, but where other SIP
mechanisms are used:
a) the usage will require some form of prior agreement with the operator of the eP-CSCF, as to the nature of the
signalling mechanism that is to be adopted; and
b) the SIP mechanisms will have to enable the eP-CSCF to conform to the SIP requirements over the Mw reference
point to the remainder of the IP multimedia core network subsystem as specified in 3GPP TS 24.229 [3].
SDP is used for the signalling session information between the WIC and the eP-CSCF. Such SDP conforms to
requirements for SDP on the Gm reference point.
5 Functional entities
5.1 General
5.2 WIC (WebRTC IMS Client)

A WebRTC IMS Client (WIC) establishing the service control signalling path over W2 interface, that is compliant with
this specification shall implement the role of WIC capabilities defined in subclause 6.2, subclause 7.2 and
subclause 8.2.
Where SIP over websockets is used, as specified in RFC 7118 [2], and no alternative SIP profiles have been agreed
between the operator of the eP-CSCF and the operator of the WWSF, then the SIP used by the WIC over the W2
reference point shall conform to the requirements for UE over the Gm reference point as specified in
3GPP TS 24.229 [3].
When the WebSocket protocol is used, the WIC shall act as a WebSocket Client, as defined in RFC 6455 [24].
The SDP used shall conform to the requirements for UE over the Gm reference point as specified in
3GPP TS 24.229 [3] and further specified in the present document.
5.3 WWSF (WebRTC Web Server Function)

The WebRTC Web Server Function (WWSF) is the initial point of contact in the Web that controls access to the IMS
communications services for the WIC as specified in 3GPP TS 23.228 [4].
5.4 WAF (WebRTC Authorisation Function)

The WebRTC Authorisation Function (WAF) issues authorization tokens that are provided to the WIC via the WWSF
as specified in 3GPP TS 23.228 [4] and 3GPP TS 33.203 [9].
NOTE: The WWSF and the WAF realisations can be physically co-located or physically separate.
5.5 eP-CSCF (P-CSCF enhanced for WebRTC)

For the Mw reference point, the eP-CSCF shall conform to the requirements for the P-CSCF as specified in
3GPP TS 24.229 [3].
3GPP
Release 12 11 3GPP TS 24.371 V12.12.0 (2021-03)
Where SIP over websockets is used, as specified in RFC 7118 [2], and no alternative SIP profile have been agreed
between the operator of the eP-CSCF and the operator of the WWSF, then the SIP used by the eP-CSCF over the W2
reference point shall conform to the requirements for P-CSCF over the Gm reference point as specified in
3GPP TS 24.229 [3].
The SDP used by the eP-CSCF over the W2 reference point shall conform to the requirements for UE over the Gm
reference point as specified in 3GPP TS 24.229 [3] and further specified in the present document.
5.6 eIMS-AGW (IMS Access Gateway enhanced for WebRTC)

The functionality of the eIMS-AGW is specified in 3GPP TS 23.228 [4] and in 3GPP TS 23.334 [13].
5A Data transport
5A.1 General
Data transport is the support of TCP, UDP and the means to securely set up connections between entities, as well as the
functions for deciding when to send data: Congestion management, bandwidth estimation and so on.
5A.2 UE
A UE supporting WebRTC shall support the WebRTC non-browser functionality as specified in RFC 8825 [30]
clause 4, excluding requirements, if any, relating to specific audio and video codecs that are indirectly referenced within
the RFC 8825 [30] clause 4.
5A.3 WWSF (WebRTC Web Server Function)

There are no data transport requirements for the WWSF.
NOTE: Any application downloaded from the WWSF that requires data transport is expected to use it in
accordance with WebRTC non-browser support of data transport.
5A.4 eP-CSCF (P-CSCF enhanced for WebRTC)

The eP-CSCF and eIMS-AGW in conjunction shall support the WebRTC gateway functionality as specified in
RFC 8825 [30] clause 4, excluding requirements, if any, relating to specific audio and video codecs that are indirectly
referenced within the RFC 8825 [30] clause 4.
The eP-CSCF and eIMS-AGW in conjunction which is expected to be deployed where it can be reached with a static IP
address (as seen from the client) do not need to support Full ICE; and therefore the eP-CSCF and eIMS-AGW in
conjunction may implement ICE-Lite only (specified in RFC 5245 [22]). ICE-Lite implementations do not send
connectivity checks, so the eP-CSCF and eIMS-AGW in conjunction may choose not to send connectivity checks too,
but shall respond to the received connectivity checks. The eP-CSCF and eIMS-AGW in conjunction with a static IP
address is expected to not need to hide its location, so the eP-CSCF and eIMS-AGW in conjunction do not need to
support functionality for operating only via a TURN server (specified in RFC 5766 [40]); instead the eP-CSCF and
eIMS-AGW in conjunction may choose to produce Host ICE candidates only.
If the eP-CSCF and eIMS-AGW in conjunction serve as a media relay into another RTP domain, the eP-CSCF and
eIMS-AGW may choose to support only features available in that network. The eP-CSCF and eIMS-AGW in
conjunction do not need to support Trickle Ice (specified in RFC 8838 [39]). However, the eP-CSCF and eIMS-AGW
in conjunction shall support DTLS-SRTP (specified in RFC 5764 [6]), since this is required for interworking with
WebRTC endpoints.
3GPP
Release 12 12 3GPP TS 24.371 V12.12.0 (2021-03)
5B Data framing and securing
5B.1 General
Data framing RTP and other data formats that serve as containers, and their functions for data confidentiality and
integrity.
5B.2 UE
A UE supporting WebRTC shall support the WebRTC endpoint functionality as specified in RFC 8825 [30] clause 5,
excluding requirements, if any, relating to specific audio and video codecs that are indirectly referenced within the
RFC 8825 [30] clause 5.
5B.3 WWSF (WebRTC Web Server Function)

There are no data framing requirements for the WWSF.
NOTE: Any application downloaded from the WWSF that requires data framing is expected to use it in
accordance with WebRTC non-browser support of data framing.
5B.4 eP-CSCF (P-CSCF enhanced for WebRTC)

RFC 8825 [30] clause 5 excluding requirements, if any, relating to specific audio and video codecs that are indirectly
The eP-CSCF and eIMS-AGW in conjunction do not need to not support Bundle (specified in RFC 8843 [25]) and
RTCP multiplexing (specified in RFC 5761 [38]) and any of the related RTP/ RTCP extensions.
The eP-CSCF and eIMS-AGW in conjunction may choose to not support the Datachannel (specified in [16]).
5C Data formats
5C.1 General
Data format is codec specifications, format specifications and functionality specifications for the data passed between
systems. audio and video codecs, as well as formats for data and document sharing, belong in this category.
5C.2 UE
A UE supporting WebRTC shall support the WebRTC non-browser functionality as specified in RFC 8825 [30]
clause 6, excluding requirements to implement specific audio and video codecs.
A UE offering WebRTC access to the IMS via GPRS IP-CAN (as described in 3GPP TS 24.229 [3], annex B), EPS IP-
CAN (as described in 3GPP TS 24.229 [3], annex L), or EPC via WLAN IP-CAN (as described in 3GPP TS 24.229 [3],
annex R) shall support the speech codecs according to 3GPP TS 26.114 [34] clause 5 and the front-end handling as
specified in 3GPP TS 26.114 [34] clause 11.
A UE offering WebRTC access to the IMS via xDSL, Fiber or Ethernet IP-CAN (as described in 3GPP TS 24.229 [3],
annex E) shall support the speech codecs according to 3GPP TS 26.114 [34] clause 18.
A UE supporting WebRTC access to the IMS via GPRS IP-CAN (as described in 3GPP TS 24.229 [3], annex B), EPS
IP-CAN (as described in 3GPP TS 24.229 [3], annex L), or EPC via WLAN IP-CAN (as described in
3GPP TS 24.229 [3], annex R) and supporting video communication shall support the video codecs according to
3GPP TS 26.114 [34].
3GPP
Release 12 13 3GPP TS 24.371 V12.12.0 (2021-03)
A UE supporting WebRTC access to the IMS via xDSL, Fiber or Ethernet IP-CAN (as described in
3GPP TS 24.229 [3], annex E) and supporting video communication shall support the video codecs according to
3GPP TS 26.114 [34] clause 18.
NOTE: Media related requirements related to specific codecs, if any, to be supported by a UE supporting
WebRTC access to the IMS via IP-CAN other than GPRS IP-CAN, other than EPS IP-CAN, other than
EPC via WLAN IP-CAN and other than xDSL, Fiber or Ethernet IP-CAN are out of scope of this
specification.
5C.3 WWSF (WebRTC Web Server Function)

There are no data format requirements for the WWSF.
NOTE: Any application downloaded from the WWSF that requires data formats is expected to use it in
accordance with WebRTC non-browser support of data formats.
5C.4 eP-CSCF (P-CSCF enhanced for WebRTC)

RFC 8825 [30] clause 6, excluding requirements to implement specific audio and video codecs.
An eP-CSCF and eIMS-AGW supporting UEs offering WebRTC access to the IMS via GPRS IP-CAN (as described in
3GPP TS 24.229 [3], annex B), EPS IP-CAN (as described in 3GPP TS 24.229 [3], annex L), or EPC via WLAN IP-
CAN (as described in 3GPP TS 24.229 [3], annex R) shall support the codecs according to 3GPP TS 26.114 [34]
clause 5.
An eP-CSCF and eIMS-AGW supporting UEs offering WebRTC access to the IMS via xDSL, Fiber or Ethernet IP-
CAN (as described in 3GPP TS 24.229 [3], annex E) shall support the codecs according to 3GPP TS 26.114 [34]
clause 18.
An eP-CSCF receiving an SDP offer from the IMS core network should retain the received codecs in the SDP offer it
sends towards the UE to avoid transcoding.
NOTE: Media related requirements related to specific codecs, if any, to be supported by a eP-CSCF supporting
WebRTC access to the IMS via IP-CAN other than GPRS IP-CAN, other than EPS IP-CAN, other than
EPC via WLAN IP-CAN, and other than xDSL, Fiber or Ethernet IP-CAN are out of scope of this
specification.
5D Connection management
5D.1 General
Connection management is setting up connections, agreeing on data formats, changing data formats during the duration
of a call; SIP and Jingle/XMPP belong in this category.
5D.2 UE
A UE supporting WebRTC shall support the WebRTC endpoint functionality as specified in RFC 8825 [30] clause 7 as
appropriate, excluding requirements, if any, relating to specific audio and video codecs that are indirectly referenced
within the RFC 8825 [30] clause 7.
5D.3 WWSF (WebRTC Web Server Function)

There are no connection management requirements for the WWSF.
NOTE: Any application downloaded from the WWSF that requires connection management is expected to use it
in accordance with WebRTC non-browser support of connection management.
3GPP
Release 12 14 3GPP TS 24.371 V12.12.0 (2021-03)
5D.4 eP-CSCF (P-CSCF enhanced for WebRTC)

RFC 8825 [30] clause 7 excluding requirements, if any, relating to specific audio and video codecs that are indirectly
The eP-CSCF and eIMS-AGW in conjunction do not need to support Trickle Ice, Bundle (specified in RFC 8843 [25])
and RTCP multiplexing (specified in RFC 5761 [38]).
5E Presentation and control
5E.1 General
Presentation and control is what needs to happen in order to ensure that interactions behave in a non-surprising manner.
This can include floor control, screen layout, voice activated image switching and other such functions - where part of
the system require the cooperation between parties.
5E.2 UE
A UE supporting WebRTC as a WebRTC browser shall support the WebRTC browser functionality as specified in
RFC 8825 [30] clause 8.
5E.3 WWSF (WebRTC Web Server Function)

There are no presentation and control requirements for the WWSF.
NOTE: Any application downloaded from the WWSF that requires presentation and control is expected to use it
in accordance with WebRTC browser support of presentation and control.
5E.4 eP-CSCF (P-CSCF enhanced for WebRTC)

There are no presentation and control requirements for the eP-CSCF.
5F Local system support functions
5F.1 General
Local system support functions is what needs to happen in order to ensure that interactions behave in a non-surprising
manner. This can include floor control, screen layout, voice activated image switching and other such functions - where
part of the system require the cooperation between parties.
5F.2 UE
Void.
5F.3 WWSF (WebRTC Web Server Function)

There are no local system support requirements for the WWSF.
3GPP
Release 12 15 3GPP TS 24.371 V12.12.0 (2021-03)
5F.4 eP-CSCF (P-CSCF enhanced for WebRTC)

There are no local system support functions for the eP-CSCF.
6 Registration and authentication
6.1 General
This clause specifies procedures that are related to registration of a WIC in the IM CN subsystem that are required for
support of WebRTC.
There are the following IMS registration scenarios defined in 3GPP TS 23.228 [4] Annex U. 3GPP TS 33.203 [9]
specifies the following authentication methods applying to different IMS registration scenarios separately.
a) Scenario 1: The WIC registration of individual public user identity using IMS authentication. There are two
authentication methods specified in 3GPP TS 33.203 [9], corresponding to this scenario:
1) SIP Digest authentication scheme; and
2) use of IMS AKA authentication scheme.
b) scenario 2: The WIC registration of individual public user identity based on web authentication.
1) Web authentication scheme: The registration procedure between the eP-CSCF and the IM CN subsystem
reuses the Trusted Node Authentication (TNA) procedure specified in 3GPP TS 33.203 [9]; or
c) scenario 3: The WIC registration of individual public user identity from a pool of public user identities.
1) Web authentication scheme: The registration procedure between the eP-CSCF and the IM CN subsystem reuses the
Trusted Node Authentication (TNA) procedure specified in 3GPP TS 33.203 [9]. The registration procedure of scenario
3 is basically the same with scenario 2, with the difference that, in scenario 3 it is assumed that the WWSF is provided
with a pool of public user identities and can assign public user identities within this pool.In all the registration scenarios,
it is assumed that HTTP or HTTPS connection is used between the WIC and the WWSF, where HTTPS connection is
recommended due to the security considerations.
The structure of subclause 6 is divided by functional entity as the first level, and in each subclause of a specific
functional entity, all the authentication solutions are described in the sequence of registreation scenarios.
As the media plane security mechanisms for WebRTC, i.e. DTLS-SRTP for RTP based media and DTLS/SCTP for
non-RTP based media, are mandatory to be supported in WIC and eP-CSCF, there is no need to indicate the media
plane security mechanisms in the Security-Client header field of the REGISTER request and in the Security-Server
header field of the 200 (OK) response to the REGISTER request.
The WIC and the eP-CSCF using Gm shall follow the registration procedures as described in 3GPP TS 24.229 [3] and
the procedures as described in this document in addition. For the WIC and eP-CSCF using Gm, the appropriate
signalling protocol is defined in 3GPP TS 24.229 [3] and this document.
For the WIC and eP-CSCF using non-Gm or non-SIP, the registration procedures and the signalling protocol are out of
scope of this document.

6.2.1 WIC registration of individual Public User Identity using IMS
authentication
6.2.1.1 General
When using SIP over Websockets as signalling protocol on the W2 interface:
3GPP
Release 12 16 3GPP TS 24.371 V12.12.0 (2021-03)
1) when the WIC uses registration using SIP Digest it shall follow the procedures as described in
subclause 6.2.1.2; and
2) when the WIC uses registration using IMS-AKA it shall follow the procedures described in subclause 6.2.1.3.
6.2.1.2 W2 using SIP Digest credentials

When using SIP over Websockets as signalling protocol on the W2 interface and using registration based on SIP Digest
credentials, the WIC shall use the procedures for "SIP Digest without TLS" as specified in 3GPP TS 24.229 [3].
NOTE: The WIC uses the TLS connection that was established during the WebSocket connection setup.
6.2.1.3 W2 using IMS-AKA

When using SIP over Websockets as signalling protocol on the W2 interface and when IMS AKA is used for
authenticating the WIC, the WIC shall use the IMS-AKA procedures defined in 3GPP TS 24.229 [3] with the following
modifications:
1) HTTP Digest AKAv2 as defined in RFC 4169 [33] is used instead of HTTP Digest AKA defined in
RFC 3310 [32]; and
2) IPSec security association set-up is not performed at the final stage of the authentication.
NOTE: The WIC uses the TLS connection that was established during the WebSocket connection setup to protect
the IMS signalling between the WIC and the eP-CSCF.
On sending a REGISTER request as defined in 3GPP TS 24.229 [3] for IMS AKA, the WIC shall:
1) additionally populate the Authorization header field with the "algorithm" header field parameter set to "AKAv2-
SHA-256" as defined in RFC 4169 [33]; and
2) not include the Security-Client header in the REGISTER request.
On receiving the 200 (OK) response to the REGISTER request the WIC shall not set the IPSec security association and
associated lifetime.
6.2.2 WIC registration of individual public user identity based on web

authentication
In this subclause it is assumed that SIP over Websockets is used as the signalling protocol on the W2 interface and the
user has a subscription with an individual IMPU, but uses a web identity and authentication scheme, e.g. OAuth 2.0, to
authenticate with the WWSF or the WAF.
As specified in 3GPP TS 33.203 [9], after receiving the access token from WWSF, which is issued by WAF, the WIC
shall:
- send a SIP REGISTER request to the eP-CSCF via the Websockets connection, which includes:
i) the Authorization header field with the Bearer scheme containing the access token as described in
RFC 8898 [27]; and
ii) values for the To header field and the From header field decided by the UE implementation.
NOTE: The WIC can use the access token to form the values of the To header field and the From header field.
The WIC shall obtain a new access token from the WWSF/WAF before the access token expiry period to continue to
get an access to IMS core network.
3GPP
Release 12 17 3GPP TS 24.371 V12.12.0 (2021-03)
6.2.3 WIC registration of individual public user identity from a pool of public
user identities
In this scenario it is assumed that the WWSF is provided with a pool of public user identities and can assign public user
identities within this pool. The WIC procedure is as specified in subclause 6.2.2, with the difference that the public user
identity (and private user identity) is temporarily assigned to the user and there is no linkage between the user’s web
identity that may be authenticated by an authentication service and the assigned IMS identities.
6.3 WWSF (WebRTC Web Server Function) and WAF (WebRTC

Authorisation Function)
6.3.1 WIC registration of individual public user identity using web credentials
The WWSF pushes WebRTC JavaScript to theWIC, authenticates the WIC’s web credentials and forwards the
authorization token to the WIC which is issued by WAF. Detailed web authentication procedures related to the WWSF
in W1 and W4 interface are described in 3GPP TS 33.203 [9] and will not be specifed in this document.
user identities
The WWSF and the WAF procedure is the same as specified in subclause 6.3.1, with the exception that in this scenario
the WAF authenticates only the WWSF without user involvement, and the WWSF may choose not to authenticate the
user if the user is to remain anonymous.

6.4.1 WIC registration of individual Public User Identity using IMS
authentication
6.4.1.1 Determination of IMS authentication mechanism

When the eP-CSCF receives a REGISTER request using SIP over Websockets as signalling protocol on the W2
interface, the eP-CSCF determines which IMS authentication mechanism to use as described in annex P of
3GPP TS 33.203 [9].
6.4.1.2 W2 using SIP Digest credentials

When the eP-CSCF receives a REGISTER request for "SIP Digest with TLS" using SIP over Websockets as signalling
protocol on the W2 interface, then the procedures as defined in 3GPP TS 24.229 [3] subclause 5.2.2 apply. In addition
the eP-CSCF shall:
1) if the REGISTER request was received on a pre-established TLS then:
a) if the REGISTER request does not map to an existing TLS association, and does not contain a challenge
response, not include the "integrity-protected" header field parameter;
b) if the REGISTER request does not map to an existing TLS association, and does contain a challenge
response, include an "integrity-protected" header field parameter with the value set to "tls-pending";
c) if the REGISTER request does map to an existing TLS association, include an "integrity-protected" header
field parameter with the value set to "tls-protected";
d) if the "rport" header field parameter is included in the Via header field, set the value of the "rport" header
field parameter in the Via header field to the source port of the received REGISTER request; and
3GPP
Release 12 18 3GPP TS 24.371 V12.12.0 (2021-03)
e) insert the "received" header field parameter in the Via header field containing the source IP address that the
request came from, as defined in RFC 3581 [26].
NOTE: As defined in RFC 3581 [26], the P-CSCF will insert a "received" header field parameter containing the
source IP address that the request came from, even if it is identical to the value of the "sent-by"
component.
When the eP-CSCF receives a 401 (Unauthorized) response to a REGISTER request, the eP-CSCF shall:
1) send the 401 (Unauthorized) response to the UE using the TLS session with which the associated REGISTER
request was protected.
When the eP-CSCF receives a 200 (OK) response to a REGISTER request as defined, and the registration expiration
interval value is different than zero, the eP-CSCF shall additionally:
- create an TLS association by storing and associating the UEs IP address and port of the TLS connection with the
TLS Session ID, the private user identity and all the successfully registered public user identities related to that
private user identity; and
- send the 200 (OK) response to the REGISTER request within the same TLS session to that in which the request
was protected.
6.4.1.3 W2 using IMS-AKA

When the eP-CSCF receives a REGISTER request from the WIC for IMS-AKA over a TLS session set-up prior
registration:
1) not including the Security Client header field; and
2) containing an Authorization header field with an "algorithm" header field parameter set to "AKAv2-SHA-256";
the eP-CSCF shall:
a) include the "integrity-protected" header field parameter with the value set to "tls-connected" in the Authorization
header field;
b) if the "rport" header field parameter is included in the Via header field, then set the value of the "rport" header
field parameter in the Via header field to the source port of the received REGISTER request; and
c) insert the "received" header field parameter in the Via header field containing the source IP address that the
request came from, as defined in RFC 3581 [26]:
NOTE: As defined in RFC 3581 [26], the P-CSCF will insert a "received" header field parameter containing the
source IP address that the request came from, even if it is identical to the value of the "sent-by"
component.
before forwarding the REGISTER request.
When the eP-CSCF receives a 401 (Unauthorized) response to a REGISTER request, the eP-CSCF shall:
1) send the 401 (Unauthorized) response to the UE using the TLS session with which the associated REGISTER
When the eP-CSCF receives a 200 (OK) response to a REGISTER request, and the registration expiration interval value
is different than zero, the eP-CSCF shall additionally:
- create an association by storing and associating the UEs IP address and port of the TLS connection with the TLS
Session ID, the private user identity and all the successfully registered public user identities related to that
private user identity; and
- protect the 200 (OK) response to the REGISTER request within the same TLS session to that in which the
3GPP
Release 12 19 3GPP TS 24.371 V12.12.0 (2021-03)
6.4.2 WIC registration of individual public user identity using web credentials
In this subclause it is assumed that SIP over Websockets is used as the signalling protocol on the W2 interface. Upon
receiving the SIP REGISTER request from the WIC, the eP-CSCF shall extract from the Authorization header field the
access token and validate it as specified in 3GPP TS 33.203 [9] Annex X. If the access token is verified valid, the eP-
CSCF obtains the associated authorization information, including the private user identity and public user identity of the
associated user, the WAF and WWSF identities, and the authorization information scope.
The eP-CSCF inserts the obtained private user identity and public user identity in the SIP REGISTER request, where
the Authorization header field in SIP REGISTER request, as specified in 3GPP TS 33.203 [9] Annex U, contains the
private user identity, and the To and From header fields in the SIP REGISTER request contains the public user identity.
NOTE: The eP-CSCF will overwrite the To header field and From header field values received in the SIP
REGISTER request from the WIC.
Then the eP-CSCF performs as the trusted node in TNA scheme specified in 3GPP TS 33.203 [9] Annex U. The eP-
CSCF forwards the SIP REGISTER request to the S-CSCF as specified in 3GPP TS 24.229 [3], where the
Authorization header in SIP REGISTER request, as specified in 3GPP TS 33.203 [9] Annex U, contains the user’s
private user identity, an "integrity-protected" header field set to "auth-done ", and an empty "response" header field.
If the WAF, which authorizes the WIC to access the IMS core and issues the access token, is located in third party
domain, the eP-CSCF shall also include the WAF identity in the REGISTER request, using a JSON Web Token
(defined in RFC 7519 [35]) with a "3gpp-waf" JSON Web Token claim (defined in 3GPP TS 24.229 [3]) set to the
value of the WAF identity. The eP-CSCF shall include the JSON Web Token in the REGISTER request as a MIME
body with an "application/jwt" MIME value (defined in RFC 7519 [35]).
If the WWSF, which authorizes the WIC to access the IMS core and issues the access token, is located in third party
domain, the eP-CSCF shall also include the WWSF identity in the REGISTER request, using a JSON Web Token with
a "3gpp-wwsf" JSON Web Token claim (defined in 3GPP TS 24.229 [3]) set to the value of the WWSF identity. The
eP-CSCF shall include the JSON Web Token in the REGISTER request as a MIME body with an "application/jwt"
MIME value (defined in RFC 7519 [35]).
If the eP-CSCF includes a JSON Web Token in the REGISTER request, it shall include a JSON Web Token header
"alg" property with a "none" value. In addition, the eP-CSCF shall not calculate and include a signature in the JSON
Web Token, as described in RFC 7519 [35].
NOTE: If the eP-CSCF includes both the WAF identity and the WWSF identity in the REGISTER request then
both identities are placed in the same JSON Web Token.
Upon receiving the SIP 200 (OK) response from the S-CSCF, the eP-CSCF forwards SIP 200 (OK) response to the
WIC. When TLS is used between the WIC and the eP-CSCF, the eP-CSCF shall additionally create an association
between the UE and the TLS connection as specified in 3GPP TS 24.229 [3] subclause 5.2.2.4.
user identities
As specified in subclause 6.4.2 with the following addition:
- An as option, upon receiving the SIP REGISTER request from the WIC, if the registration expiration interval
(specified in 3GPP TS 24.229 [3]) contains a value higher than the lifetime of the authorization token, then in
order to allow the WWSF to know when to re-assign a public user identity and private user identity to another
user, the eP-CSCF may set a value for the registration expiration interval in the SIP REGISTER request equal to
the lifetime of the authorization token. Other options may exist.
3GPP
Release 12 20 3GPP TS 24.371 V12.12.0 (2021-03)
6A Deregistration
6A.1 General
This clause specifies procedures that are related to deregistration in the IM CN subsystem that are required for support
of WebRTC.
The WIC and the eP-CSCF using Gm shall follow the deregistration procedures as described in 3GPP TS 24.229 [3]
and the procedures as described in this document in addition. For the WIC and the eP-CSCF using Gm, the appropriate
signalling protocol is defined in 3GPP TS 24.229 [3] and this document.
For the WIC and eP-CSCF using non-Gm or non-SIP, the deregistration procedures and the signalling protocol are out
of scope of this document.
6A.2 WIC (WebRTC IMS Client)

It is assumed that the WIC has previously registered, and the signalling protocol between the WIC and the eP-CSCF
applies SIP over WebSockets where the SIP procedures conform to the definitions for SIP on the Gm reference point as
specified in 3GPP TS 24.229 [3].
The WIC shall follow the deregistration procedures speicifed in 3GPP TS 24.229 [3] subclause 5.1.1.6 and
subclause 5.1.1.7.
If the WIC have no more public user identities registered in the IM CN subsystem, the WebSockets connection between
the WIC and the eP-CSCF shall be removed.
6A.3 eP-CSCF (P-CSCF enhanced for WebRTC)

The eP-CSCF shall follow the deregistration procedures speicifed in 3GPP TS 24.229 [3] subclause 5.2.5.1 and
subclause 5.2.5.2.
NOTE: In the scenario that individual public user identity is assigned by the WWSF or the WAF from a pool of
public user identities, as an implementation specific option, when the public user identity has been
deregistered in the IM CN subsystem, the eP-CSCF can indicate to the WAF that a certain public user
identity can be re-assigned, while the procedures for the interface between the eP-CSCF and the WAF is
out of scope of this specification.
7 Call origination and termination
7.1 General
This clause specifies procedures that are related to call origination and termination in the IM CN subsystem that are
required for support of WebRTC.
It is assumed that prior to the call origination and termination procedure, a WebSockets connection hase been
established between the WIC and the eP-CSCF. The call control signalling between the WIC and the eP-CSCF is
transport over the WebSockets connection.
The WIC shall support ICE procedures as described in RFC 5245 [22] and RFC 6544 [28], with the additions specified
in RFC 7675 [21]. The WIC shall perform ICE procedures when initiated by other subclauses in this document.
3GPP
Release 12 21 3GPP TS 24.371 V12.12.0 (2021-03)
7.2.1 General
The WIC shall support RFC 5763 [5] and RFC 5764 [6].
The WIC using Gm shall follow the procedures as described in 3GPP TS 24.229 [3]. For the WIC using Gm, the
appropriate signalling protocol is defined in 3GPP TS 24.229 [3]. The WIC using Gm shall include the Authorization
header field with the Bearer scheme containing the valid access token in all SIP requests, as specified in draft-ietf-
sipcore-sip-token-authnz [27].
The WIC using non-Gm SIP shall support RFC 3261 [19]. For the WIC using non-Gm, the appropriate signalling
protocol is defined in RFC 3261 [19].
The WIC using non-SIP shall support RFC 3264 [20]. For the WIC using non-SIP, the appropriate signalling protocol is
out of scope of this specification.
7.2.2 WIC originating call

When the WIC originates a call, the WIC shall:
a) perform the ICE procedures as defined in RFC 5245 [22] and possibly RFC 6544 [28]; and
b) generate an SDP offer and send it towards the eP-CSCF using the appropriate signalling protocol as described in
subclause 7.2.1.
Upon generating an SDP offer with RTP based media, for each RTP based media, the WIC
a) shall offer UDP transport protocol according RFC 5763 [5], with the proto field in the "m=" line containing the
"UDP/TLS/RTP/SAVPF" value according to RFC 5764 [6];
b) may additionally, within the same "m=" line, offer TCP transport protocol with appropriate ICE candidates
according to RFC 6544 [28]; and
c) shall additionally, within the same "m=" line, indicate an SDP "a=3ge2ae:requested" attribute.
7.2.3 WIC terminating call

Upon receipt of an SDP offer, the WIC shall:
a) perform the ICE procedures as defined in RFC 5245 [22] and possibly RFC 6544 [28]; and
b) generate an SDP answer and send it towards the eP-CSCF using the appropriate signalling protocol as described
in subclause 7.2.1.
Upon receiving an SDP offer containing an RTP based media:
- transported using RFC 5763 [5], with the proto field in the "m=" line containing the "UDP/TLS/RTP/SAVPF"
value according to RFC 5764 [6]; and
- with the SDP "a=3ge2ae:applied" attribute;
and if the UE accepts the RTP based media, then the UE shall generate the SDP answer with the related RTP based
media transported. In order to do so, the UE:
a) shall use RFC 5763 [5], and provide the proto field in the "m=" line containing the "UDP/TLS/RTP/SAVPF"
according to RFC 6544 [28].
7.2.4 WIC emergency call

A WIC shall not attempt to establish a session when the WIC can detect that the number dialled is an emergency
number.
3GPP
Release 12 22 3GPP TS 24.371 V12.12.0 (2021-03)
NOTE 1: Emergency calls originated from a WIC are not supported in this version of the specification.
If a WIC
a) receives a response indicating that a UE non detected emergency call has happened and was not supported by the
network; and
b) supports detecting such responses as indicating UE non detected emergency call;
then the WIC shall:
1) indicate to the user that an attempt for an UE non detected emergency call has happened and was not supported
by the network; and
2) not retry the emergency call via W2 interface.
If Gm based W2 is used, then the response indicating rejection of a request for a UE non detected emergency call is a
380 (Alternative Service) response with contents as specified in 3GPP TS 24.229 [3] subclause 5.2.10.4.
NOTE 2: The details how to indicate the rejection of a UE non detected emergency call to the user are not
specified.

No additional procedure is specified for WWSF.

7.4.1 General
The eP-CSCF using Gm towards the WIC shall follow the procedures as described in 3GPP TS 24.229 [3]. For the eP-
CSCF using Gm, the appropriate signalling protocol is defined in 3GPP TS 24.229 [3].
The eP-CSCF using non-Gm SIP towards the WIC shall support RFC 3261 [19]. For the eP-CSCF using non-Gm, the
appropriate signalling protocol is defined in RFC 3261 [19].
The eP-CSCF using non-SIP towards the WIC shall support RFC 3264 [20]. For the eP-CSCF using non-SIP, the
appropriate signalling protocol is out of scope of this specification.
The eP-CSCF shall support RFC 5763 [5] and RFC 5764 [6].

Upon receipt of an SDP offer, the eP-CSCF shall:
a) perform ICE procedures as defined in 3GPP TS 24.229 [3]; and
b) generate an SDP offer based on the SDP offer received from the WIC and forward it using the appropriate
signalling protocol as described in subclause 7.4.1. The eP-CSCF shall replace the SDP offer with updated SDP
provided by eIMS-AGW, which contains the eIMS-AGW IP addresses and ports. The eP-CSCF shall not use
bundled media as described in RFC 8843 [25], i.e. the eP-CSCF shall remove the SDP group attribute BUNDLE
value, and any m- line that in the received SDP offer contained an SDP "bundle-only" attribute, from the SDP
offer.
NOTE: At this point, the eP-CSCF interacts with eIMS-AGW to reserve resources and provide the information
needed for media handling. The details of the interaction between eP-CSCF and eIMS-AGW are out of
scope of this document.
Upon receiving an SDP offer from the served WIC containing an DTLS-SRTP based media stream with end-to-access-
edge protection, i.e. an "m=" line:
- with the proto field containing the "UDP/TLS/RTP/SAVPF" value as specified in RFC 5764 [6]; and
3GPP
Release 12 23 3GPP TS 24.371 V12.12.0 (2021-03)
- with the SDP "a=3ge2ae:requested" attribute or, if permitted by operator policy, without the SDP
"a=3ge2ae:requested" attribute;
the eP-CSCF shall invoke IMS-ALG procedures, shall remove the SDP "a=3ge2ae:requested" attribute, if included,
and the SDP fingerprint attribute and shall act as defined in 3GPP TS 24.229 [3] as far as SDP and RTP is concerned.
Upon receiving an SDP answer over the Mw interface, for each DTLS-SRTP based media stream with end-to-access-
edge protection of the SDP offer from the served WIC which is accepted in the received SDP answer, the eP-CSCF
shall invoke IMS-ALG procedures.In the SDP answer to served WIC the transport protocol, the eP-CSCF
a) shall use to RFC 5763 [5] and shall provide the proto field in the "m=" line withthe "UDP/TLS/RTP/SAVPF"
according to RFC 6544 [28].
If the SDP offer contained bundled media as described in RFC 8843 [25], the eP-CSCF shall reject the bundling of
media, i.e. the eP-CSCF shall not add a SDP group BUNDLE attribute to the SDP answer, and the eP-CSCF shall
assign a zero port value to any m- line that in the SDP offer contained an SDP "bundle-only" attribute.
NOTE: Stage 2 has specified that the architecture does not support media multiplexing that is defined for
WebRTC, so the SDP answer sent to the served WIC will not contain bundled media.

Upon receiving an SDP offer over the Mw interface with an RTP based media, for each RTP based media, the eP-
CSCF:
1) shall invoke IMS-ALG procedures;
2) shall perform ICE procedures as defined in 3GPP TS 24.229 [3]; and
3) in the SDP offer to served WIC:
- shall indicate the transport protocol according to RFC 5763 [5], with the proto field in the "m=" line containing
the "UDP/TLS/RTP/SAVPF" value according to RFC 5764 [6];
- may additionally, within the same "m=" line, offer TCP transport protocol with appropriate ICE candidates
according to RFC 6544 [28]; and
- shall include the SDP "a=3ge2ae:applied" attribute.
NOTE: Stage-2 has specified that the architecture does not support media multiplexing that is defined for
WebRTC, so the SDP offer sent to the served WIC will not contain bundled media.
Upon receipt of an SDP answer, the eP-CSCF:
a) shall perform ICE procedures as defined in3GPP TS 24.229 [3];
b) shall generate an SDP answer based on the SDP answer received from the WIC and forward it using the
appropriate signalling protocol as described in subclause 7.4.1;
c) for each RTP based media of the SDP offer from the remote UE which is accepted in the SDP answer:shall
remove the SDP fingerprint attribute; and
d) shall act as defined in 3GPP TS 24.229 [3] as far as SDP and RTP is concerned.
7.4.4 WIC emergency call

If the eP-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown method, for a
registered user, the eP-CSCF shall inspect the Request-URI. The eP-CSCF shall consider the Request URI of the initial
request as a emergency service identifier, if it is an emergency numbers or an emergency service URN from the
configurable lists that are associated with:
1) the country of the operator to which the eP-CSCF belongs to; and
3GPP
Release 12 24 3GPP TS 24.371 V12.12.0 (2021-03)
2) the country of roaming partners, if the request originates from a different country then the country of the network
to which the eP-CSCF belongs to. If Gm based W2 is used, then access technology specific procedures are
described in each access technology specific annex of 3GPP TS 24.229 [3] to determine from which country and
roaming partner the request was originated; and
3) if the country from which the request originates cannot be determined then all lists are associated.
If the eP-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone transaction, or an
unknown method matches one of the emergency service identifiers in the associated lists then the eP-CSCF shall:
A) If item 1) applies then determine whether the request originates from the same country as the country of the
network to which the eP-CSCF belongs. If Gm based W2 is used, then access technology specific procedures are
used as described in each access technology specific annex of 3GPP TS 24.229 [3] to determine from which
country and roaming partner the request was originated. If the request originates from the same country, then the
eP-CSCF depending on operator policy shall:
a) reject the request as appropriate for the signalling in use. If Gm based W2 is used, then send 380 (Alternative
Service) response with the contents as specified in 3GPP TS 24.229 [3] subclause 5.2.10.4; or
b) proceed the request as specified in of 3GPP TS 24.229 [3] sub-clause 5.2.10.4 for the case where the request
is not rejected; or
B) in all other cases the eP-CSCF shall reject the request as appropriate for the signalling in use. If Gm based W2 is
used, then send a 380 (Alternative Service) response with the contents as specified in 3GPP TS 24.229 [3]
subclause 5.2.10.4.
8 Data channel open and close
8.1 General
This clause specifies the procedures for negotiating usage of, and opening and closing of, a WebRTC data channel
between the WIC and the eP-CSCF.
WebRTC data channels are realized using an SCTP association running on top of DTLS, as described in RFC 8261 [23]
and RFC 8831 [16]. Once the SCTP association has been negotiated and established, the WIC and eIMS-AGW
(controlled by the eP-CSCF) use the Data Channel Establishment Protocol (DCEP) for opening and closing data
channels, as described in RFC 8832 [17].
NOTE: Procedures for the use of data channel to transport other protocols, e.g. MSRP, BFCP and T.140 are not
specified in the present release.

8.2.1 General
The WIC shall follow the general call establishment procedures in subclause 7. This subclause defines the additional
procedures for establishing WebRTC data channels within the call.
NOTE 1: A mechanism for the WIC and eP-CSCF to inform each other, during the negotiation of the SCTP
association, for what purposes data channels will be used, is outside the scope of the current release of the
specification. Before DCEP is used to open the data channels, the purpose of the data channels can be
determined based e.g. on configuration, or can be determined based on information carried in the
signalling protocol between the WIC and the eP-CSCF. This may not be possible in all scenarios.
NOTE 2: Identification of multiple data channels is not specified in this version of the document.
3GPP
Release 12 25 3GPP TS 24.371 V12.12.0 (2021-03)

Upon generating an SDP offer, the WIC shall insert an "m=" line with the proto value set to "UDP/DTLS/SCTP" or
"TCP/DTLS/SCTP", and the fmt value set to "webrtc-datachannel" according to RFC 8841 [18], in the SDP offfer. In
addition, the WIC shall insert an SDP sctp-port attribute according to RFC 8841 [18].

Upon receiving an SDP offer, with an "m=" line with the proto value set to "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP",
and the "m=" line fmt value set to "webrtc-datachannel", the WIC shall follow the procedures in RFC 8841 [18] for
generating the associated SDP answer. In addition, the WIC shall insert an SDP sctp-port attribute according to
RFC 8841 [18].

8.4.1 General
The eP-CSCF shall follow the general call establishment procedures in clause 7. This subclause defines the additional
procedures for establishing WebRTC data channels within the call.
In the current release of the specification, the eIMS-AGW will act as an endpoint for all WebRTC data channels
established between the eIMS-AGW and the served WIC. If the eIMS-AGW is able to perform transport protocol
interworking for a media transported between the eIMS-AGW and the served WIC using a data channel, and between
the eIMS-AGW and the remote user using another transport protocol, the eP-CSCF can instruct the eIMS-AGW to
perform transport protocol interworking between the data channel and the other transport protocol.
NOTE 1: In this release the H.248 protocol aspects to establish and control data channels for the split architecture
between the eP-CSCF and the eIMS-AGW are not specified.
NOTE 2: A mechanism for the WIC and eP-CSCF to inform each other, during the negotiation of the SCTP
association, for what purposes data channels will be used, is outside the scope of the current release of the
specification. Before DCEP is used to open the data channels, the purpose of the data channels can be
determined based e.g. on configuration, or can be determined based on information carried in the
signalling protocol between the WIC and the eP-CSCF. This may not be possible in all scenarios.
NOTE 3: Identification of multiple data channels is not specified in this version of the document.

Upon receiving an SDP offer from the served WIC, with an "m=" line with the proto value set to "UDP/DTLS/SCTP"
or "TCP/DTLS/SCTP", and the fmt value set to "webrtc-datachannel", according to RFC 8841 [18], the eP-CSCF shall:
- remove the "m=" line from the SDP offer; and
- for each media transported between the WIC and the eIMS-AGW using a data channel, and for which the eIMS-
AGW is able to perform transport protocol interworking between a data channel and another transport protocol,
insert an "m=" line describing the media and the transport protocol used for the media in the SDP offer;
before forwarding the SDP offer towards the remote user.
Upon receiving an SDP answer to the SDP offer, the eP-CSCF shall:
- remove each "m=" line associated with an "m=" line that the eP-CSCF inserted in the associated SDP offer from
the SDP answer;
- insert an "m=" line with the proto value set to "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP", and the fmt value set
to "webrtc-datachannel" according to RFC 8841 [18], in the SDP answer;
3GPP
Release 12 26 3GPP TS 24.371 V12.12.0 (2021-03)
- insert an SDP sctp-port attribute according to RFC 8841 [18], in the SDP answer; and
- for each media accepted by the remote user, for which the eIMS-AGW can perform transport protocol
interworking between a data channel and another transport protocol, instruct the eIMS-AGW to perform the
transport protocol interworking;
before forwarding the SDP answer towards the served WIC.

Upon receiving an SDP offer from the remote user, the eP-CSCF shall:
- remove each "m=" line that describes media which is transported between the WIC and the eIMS-AGW using a
data channel from the SDP offer;
- insert an "m=" line with the proto value set to "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP", and the fmt value set
to "webrtc-datachannel" according to RFC 8841 [18], in the SDP offer; and
- insert an SDP sctp-port attribute according to RFC 8841 [18], in the SDP answer;
before forwarding the SDP offer towards the served WIC.
Upon receiving an SDP answer to the SDP offer, with an "m=" line with the proto value set to "UDP/DTLS/SCTP" or
"TCP/DTLS/SCTP", and the fmt value set to "webrtc-datachannel", according to RFC 8841 [18], the eP-CSCF shall:
- remove the the "m=" line from the SDP answer;
- for each media which the eIMS-AGW is able to perform transport protocol interworking between a data channel
and another transport protocol, and for which the SDP offer contained an "m=" line, insert an "m=" line
describing the media and the transport protocol used for the media in the SDP answer; and
- for each media accepted by the remote user, for which the eIMS-AGW can perform transport protocol
interworking between a data channel and another transport protocol, instruct the eIMS-AGW to perform the
transport protocol interworking;
before forwarding the SDP answer towards the remote user.
9 Call modification
WIC and eP-CSCF shall behave in accordance with the procedures specified in subclause 7. There is no additional
requirement specified within this release.
10 IP multimedia application support in the IM CN

subsystem using webRTC
10.1 General
10.2 Access to MMTel and supplementary services using webRTC

10.2.1 General
This clause describes the procedures for interaction of WebRTC based access to the IM CN subsystem and the
execution of supplementary service as described in 3GPP TS 22.173 [7].
3GPP
Release 12 27 3GPP TS 24.371 V12.12.0 (2021-03)
10.2.2 WIC (WebRTC IMS Client)
10.2.2.1 SIP based protocol used by the WIC

If the protocol between the WIC and the eP-CSCF is based on SIP, then in order to support an MMTel supplementary
service, the SIP procedures shall conform to the SIP procedures specified in the 24 series specification of the respective
supplementary service. 3GPP TS 24.173 [8] lists the documents defining the MMTel supplementary services.
10.2.2.2 non-SIP based protocol used by the WIC

The support of MMTel supplementary services when accessing the IM CN subsystem with non-SIP based protocol is
not specified in this version of the specification.
10.2.3 WWSF (WebRTC Web Server Function)
10.2.4 eP-CSCF (P-CSCF enhanced for WebRTC)

When a SIP is used on the W2 interface, then there are no supplementary specific requirements defined for the eP-
CSCF.
When a non-SIP protocol is used on the W2 interface, then the eP-CSCF has to map information elements from non-SIP
based protocol on W2 interface to the corresponding SIP information elements on the Mw reference point.
3GPP
Release 12 28 3GPP TS 24.371 V12.12.0 (2021-03)
Annex A (informative):
Example signalling flows
A.1 Scope of signalling flows

This annex gives examples of signalling flows for IMS based WebRTC, and the W2 interface is based on SIP protocol.
A.2 Void
A.3 Signalling flows for registration
A.3.1 Void
A.3.2 WIC registration of individual public user identity based on

web authentication
Figure A.3.2-1 shows the registration signalling flow for the scenario when the user has a subscription with an
individual public user identity, but uses a web identity and authentication scheme, e.g. OAuth 2.0, to authenticate with
the WWSF or the WAF.
3GPP
Release 12 29 3GPP TS 24.371 V12.12.0 (2021-03)
UE#1 WWSF/WAF eP-CSCF I/S-CSCF
1. Download the WIC and obtains

access token from WWSF/WAF
2. Establish secure WebScoket connection
3. REGISTER
4. Validation of token at eP-CSCF
5. REGISTER
6. Registration related
processing at S-CSCF
7. 200 OK
8. 200 OK
Figure A.3.2-1: WIC registration of individual public user identity based on web authentication
1. Download WIC and obtain access token
The user accesses a WebRTC URI to the WWSF. The browser downloads and initializes the WIC from the
WWSF. The WAF or WWSF, depending on the authorization flow (e.g. OAuth 2.0) used, authenticates the user
via "web credentials", i.e. credentials as commonly used for access to web based services, for example a
username and password. The user's web identity is mapped to the corresponding IMS subscriber identity (i.e.
private user identity and public user identity). The WWSF forwards the access token and the IMS identity to the
WIC.
2. Establishment of secure connection between WIC and eP-CSCF
The WIC opens a WSS (secure Web Socket) connection to the eP-CSCF. The TLS connection provides one-way
authentication of the server based on the server certificate.
3. REGISTER request (WebRTC IMS Client to eP-CSCF)
The WebRTC IMS Client sends a REGISTER request to eP-CSCF. The REGISTER request includes an
Authorization header field with the Bearer scheme containing the access token, which the WebRTC IMS Client
has previously obtained.
Table A.3.2-1: Authorization header field in the REGISTER request (WIC to eP-CSCF)
Authorization: Bearer access_token="O91G451HZ0V83opz6udiSEjchPynd2Ss9......"
3GPP
Release 12 30 3GPP TS 24.371 V12.12.0 (2021-03)
Authorization: It carries the access token previously obtained from WWSF/WAF in the web authentication
procedure, and the type of the access token (i.e. "Bearer" OAuth access token type (defined in
RFC 6750 [10]) in this example).
4. Validation of security token at eP-CSCF
The eP-CSCF extracts from the Authorization header field the access token and validates it in some unspecified
manner ensuring that only an authorized source can have the generated access token. If the access token is valid
the eP-CSCF obtains the associated authorization information, including the private user identity and public user
identity of the associated user, the WWSF identity, and the access token scope.
5. REGISTER request (eP-CSCF to S-CSCF)
The eP-CSCF proceeds if the previous step has provided it with private user identity and public user identity(s)
of the user requesting registration, an assurance that the user is authorised to use this private user identity and
public user identity, and an identity of the WWSF and WAF. Then, the eP-CSCF generates an Authorization
header field and forwards the request to the S-CSCF (via the I-CSCF).
Table A.3.2-2: Authorization header field in the REGISTER request (eP-CSCF to I/S-CSCF)
Authorization: Digest username="[email protected]", realm="registrar.home1.net",
nonce="", uri="sip:registrar.home1.net", response="", integrity-protected="auth-done"
Authorization: It contains the user’s private user identity, an "integrity-protected" header field set to "auth-done ",
and an empty "response" header field.
6. S-CSCF Registration
Based on the presence of the "integrity-protected" directive set to indicate that authentication has already been
performed, the S-CSCF knows that user’s authorization has already been validated by the Trusted Node. The S-
CSCF informs the HSS that the user has been registered. Upon being requested by the S-CSCF, the HSS will
also include the user profile in the response sent to the S-CSCF. If the S-CSCF receives the identity of the WAF
in the Authorization header field, the S-CSCF shall further checks whether the identity of the authorization entity
received from the eP-CSCF, if any, is not barred, as described in 3GPP TS 33.203 [9] Annex U.
7. 200 (OK) response (S-CSCF to eP-CSCF)
The S-CSCF sends a 200 (OK) response to the eP-CSCF (via I-CSCF) indicating that Registration was
successful.
When TLS is used between WIC and eP-CSCF, then, similar to the registration procedure for SIP Digest with
TLS, the eP-CSCF associates the private user identity and all successfully registered public user identitis with
the TLS Session ID when the 200 (OK) is received.
8. 200 (OK) response (eP-CSCF to UE)
The eP-CSCF forwards the 200 (OK) response to the WebRTC IMS Client indicating that Registration was
successful.
A.3.3 Void
A.4 Void
A.5 Void
3GPP
Release 12 31 3GPP TS 24.371 V12.12.0 (2021-03)
Annex B (informative):
Change history
Change history
Date TSG # TSG Doc. CR Rev Subject/Comment Old New
2014-04 CT1#86bis C1-141590 Initial version 0.1.0
C1-141591
2014-05 CT1#87 C1-142082 This version contains the changes of agreed CRs at CT1#87 0.2.0
C1-142326
C1-142327
C1-142328
C1-142408
C1-142409
C1-142433
C1-142435
C1-142523
2014-07 CT1#88 C1-142859 This version contains the changes of agreed CRs at CT1#88 0.3.0
C1-142861
C1-142863
C1-143208
C1-143209
C1-143210
C1-143211
C1-143213
C1-143220
C1-143279
C1-143280
C1-143281
C1-143328
C1-143330
C1-143332
C1-143377
C1-143378
2014-09 CT-65 CP-140627 Version 1.0.0 presented for information at CT plenary 0.3.0 1.0.0
2014-10 CT1#88bis C1-144087 This version contains the changes of agreed CRs at CT1#88bis 1.0.0 1.1.0
C1-144094
C1-144187
C1-144190
C1-144227
C1-144258
C1-144272
C1-144273
2014-11 CT1#89 C1-144313 This version contains the changes of agreed CRs at CT1#89 1.1.0 1.2.0
C1-144894
C1-144915
C1-144916
C1-144917
C1-144993
C1-144994
2014-12 CT-66 CP-140808 Version 2.0.0 presented for approval at CT plenary 1.2.0 2.0.0
2014-12 CT-66 CP-140990 Version 2.1.0 after approval and integration of CR in CP-141004 2.0.0 2.1.0
2014-12 CT-66 Version 12.0.0 after approval at CT plenary 2.1.0 12.0.0
2015-03 CT-67 CP-150072 0001 1 IMS WebRTC reference updates 12.0.0 12.1.0
2015-03 CT-67 CP-150072 0003 3 Codec support in IMS-WebRTC 12.0.0 12.1.0
2015-06 CT-68 CP-150317 0004 2 WebRTC codec when using EPC via WLAN IP-CAN and fixed 12.1.0 12.2.0
access
2015-06 CT-68 CP-150317 0005 1 Data channel usage 12.1.0 12.2.0
2015-06 CT-68 CP-150317 0006 2 Contents of To and From headers for WIC registration based on 12.1.0 12.2.0
web-authentication
2015-06 CT-68 CP-150317 0007 2 Coordination between the IMS Provider and WWSF Provider on 12.1.0 12.2.0
lifetime of the REGISTER.
2015-06 CT-68 CP-150317 0008 1 Clarification about when eP-CSCF obtains the WAF identity and 12.1.0 12.2.0
some editorial corrections
2015-06 CT-68 CP-150317 0011 W2 using SIP Digest credentials 12.1.0 12.2.0
2015-06 CT-68 CP-150317 0012 1 Update reference version of gateways draft 12.1.0 12.2.0
2015-06 CT-68 CP-150317 0013 1 380 handling for eP-CSCF and WIC 12.1.0 12.2.0
2015-06 CT-68 CP-150317 0014 1 eIMS-AGW to be documented 12.1.0 12.2.0
2015-09 CT-69 CP-150518 0015 WebRTC codec in IP-CANs other than EPS IP-CAN, GPRS IP- 12.2.0 12.3.0
CAN, EPC via WLAN IP-CAN, and xDSL, Fiber or Ethernet IP-CAN
2015-09 CT-69 CP-150518 0017 1 No H.248 support for Data Channels 12.2.0 12.3.0
3GPP
Release 12 32 3GPP TS 24.371 V12.12.0 (2021-03)
2015-09 CT-69 CP-150518 0018 2 SDP usage for WebRTC 12.2.0 12.3.0
2015-09 CT-69 CP-150518 0020 3 UE undetected emergency call 12.2.0 12.3.0
2015-12 CT-70 CP-150693 0023 1 JSON Web Token claims for transport of WAF and WWSF 12.3.0 12.4.0
identities
2015-12 CT-70 CP-150693 0025 Reference update: RFC 7675 (draft-ietf-rtcweb-stun-consent- 12.3.0 12.4.0
freshness)
2015-12 CT-70 CP-150693 0027 Reference update: draft-ietf-mmusic-sdp-bundle-negotiation 12.3.0 12.4.0
2015-12 CT-70 CP-150693 0029 Reference update: draft-yusef-sipcore-sip-oauth 12.3.0 12.4.0
2015-12 CT-70 CP-150693 0031 1 Reference update: draft-ietf-mmusic-sctp-sdp 12.3.0 12.4.0
2015-12 CT-70 CP-150693 0033 1 Reference update: draft-ietf-mmusic-proto-iana-registration 12.3.0 12.4.0
2015-12 CT-70 CP-150693 0035 Reference update: draft-ietf-tsvwg-sctp-dtls-encaps 12.3.0 12.4.0
2015-12 CT-70 CP-150693 0037 Reference update: draft-ietf-rtcweb-overview 12.3.0 12.4.0
2015-12 CT-70 CP-150693 0039 Reference update: draft-ietf-rtcweb-gateways 12.3.0 12.4.0
2016-06 CT-72 CP-160301 0045 2 References update 12.4.0 12.5.0
Change history
Date Meeting TDoc CR Rev Cat Subject/Comment New
version
2016-12 CT-74 CP-160715 0054 F WebRTC data channel corrections 12.6.0
2017-06 CT-76 CP-171057 0071 2 F References on webrtc-overview and sctp-sdp update 12.7.0
2017-06 CT-76 CP-171057 0078 2 F Removing references to draft-ietf-rtcweb-gateways. 12.7.0
2017-09 CT-77 CP-172085 0081 F Reference update: draft-ietf-sipcore-sip-authn 12.8.0
2018-03 CT-78 CP-180058 0084 F Reference update: RFC 8261 12.9.0
2019-09 CT-85 CP-192038 0091 F Reference update: draft-ietf-sipcore-sip-token-authnz 12.10.0
2020-12 CT-90e CP-203191 0100 1 F Reference update: RFC 8898 12.11.0
2021-03 CT-91e CP-210097 0116 F Reference updates RFCs in IMS_WebRTC 12.12.0
3GPP

3GPP TS 24.371: Technical Specification

Uploaded by

Copyright:

Available Formats

3GPP TS 24.371: Technical Specification

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3GPP TS 24.371: Technical Specification

Uploaded by

Copyright:

Available Formats

3rd Generation Partnership Project;

Technical Specification Group Core Network and Terminals;

3GPP support office address

No part may be reproduced except as authorized by written permission.

Annex A (informative): Example signalling flows......................................................................................28

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.

- For a specific reference, subsequent revisions do not apply.

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

[4] 3GPP TS 23.228: " IP Multimedia Subsystem (IMS); Stage 2".

[9] 3GPP TS 33.203: "Access security for IP based services".

[11] 3GPP TS 23.292: "IP Multimedia Subsystem (IMS) Centralized Services; Stage 2".

[16] RFC 8831 (January 2021): "WebRTC Data Channels".

[17] RFC 8832 (January 2021): "WebRTC Data Channel Establishment Protocol".

[18] RFC 8841 (January 2021): "Stream Control Transmission Protocol (SCTP)-Based Media

[19] RFC 3261 (June 2002): "SIP: Session Initiation Protocol".

[21] RFC 7675 (October 2015): "STUN Usage for Consent Freshness".

[23] RFC 8261 (November 2017): "Datagram Transport Layer Security (DTLS) Encapsulation of

[27] RFC 8898 (September 2020): "Third-Party Token-Based Authentication and Authorization for

[30] RFC 8825 (January 2021): "Overview: Real-Time Protocols for Brower-Based Applications".

[35] RFC 7519 (May 2015): "JSON Web Token (JWT)".

3 Definitions and abbreviations

P-CSCF enhanced for WebRTC (eP-CSCF)

4 Overview of WebRTC access to IMS

5.2 WIC (WebRTC IMS Client)

5.3 WWSF (WebRTC Web Server Function)

5.4 WAF (WebRTC Authorisation Function)

5.5 eP-CSCF (P-CSCF enhanced for WebRTC)

5.6 eIMS-AGW (IMS Access Gateway enhanced for WebRTC)

5A.3 WWSF (WebRTC Web Server Function)

5A.4 eP-CSCF (P-CSCF enhanced for WebRTC)

5B Data framing and securing

5B.3 WWSF (WebRTC Web Server Function)

5B.4 eP-CSCF (P-CSCF enhanced for WebRTC)

5C.3 WWSF (WebRTC Web Server Function)

5C.4 eP-CSCF (P-CSCF enhanced for WebRTC)

5D.3 WWSF (WebRTC Web Server Function)

5D.4 eP-CSCF (P-CSCF enhanced for WebRTC)

5E Presentation and control

5E.3 WWSF (WebRTC Web Server Function)

5E.4 eP-CSCF (P-CSCF enhanced for WebRTC)

5F Local system support functions

5F.3 WWSF (WebRTC Web Server Function)

5F.4 eP-CSCF (P-CSCF enhanced for WebRTC)

6 Registration and authentication

1) SIP Digest authentication scheme; and

2) use of IMS AKA authentication scheme.

6.2 WIC (WebRTC IMS Client)

6.2.1.2 W2 using SIP Digest credentials

6.2.1.3 W2 using IMS-AKA

2) not include the Security-Client header in the REGISTER request.

6.2.2 WIC registration of individual public user identity based on web

6.3 WWSF (WebRTC Web Server Function) and WAF (WebRTC

6.4 eP-CSCF (P-CSCF enhanced for WebRTC)

6.4.1.1 Determination of IMS authentication mechanism

6.4.1.2 W2 using SIP Digest credentials

1) if the REGISTER request was received on a pre-established TLS then: