U.1 Overview
23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS
U.1.0 General
Web Real-Time Communication (WebRTC) is specified in IETF RFC 8825 [84] and WebRTC 1.0 [85]. This Annex specifies a network-based architecture for the support of WebRTC client’s access to IMS. Any requirements for specific audio and video codecs from IETF RFC 8825 [84] (directly and indirectly referenced) do not apply for WebRTC access to IMS; the codecs that shall be supported for WebRTC access to IMS are described in TS 26.114 [76].
NOTE: The UE can also perform WebRTC access to IMS by implementation specific means in the UE in which it exposes a standard Gm interface towards IMS.
U.1.1 Assumptions
– This Release specifies an option to use a signalling interface from the UE to the network based on SIP over WebSocket (RFC 7118 [89]), which is used as the information model which may be used by other options. Options other than SIP over WebSocket, such as XMPP or other application protocols over WebSocket, a RESTful based interface, etc. are allowed but not described. Alternative message body formats such as JSON and alternative transport protocols are also not precluded. Any enhancements required to accommodate an unspecified signalling interface are considered compliant to the Release as long as other defined interfaces in the architecture are not impacted.
– SDP offer/answer exchange is the mechanism used for media plane feature negotiation.
– The architecture does not support media multiplexing that is defined for WebRTC clients. A WebRTC IMS Client (WIC) accessing IMS services should not allow usage of media multiplexing in the browser.
– If an SDP offer with media multiplexing is sent to the network the part of the SDP offer associated with media multiplexing shall be removed at the entry of the IMS network.
– WebRTC specific media plane extensions will be handled at the access edge and will not be propagated to other IMS functions.
– For network based interworking between WebRTC and IMS, in the case of 3GPP and EPC access from a WebRTC client:
– Use of available techniques to select preferred access technologies and APNs/DNNs, and to provide IP address continuity, are allowed but not described.
– When the WebRTC client is served by an IP-CAN that supports PCC, it is possible to request QoS within the IP-CAN for WebRTC media.
NOTE: To ensure full end to end QoS support, proper IP forwarding policies can be set in the path between the P‑GW and the Functions supporting media interworking to the IMS.
– QoS can be provided in configurations where the IMS can identify the transport (TCP-UDP/IP) addresses handled by the PCEF and where based on this information PCC functions can identify the UE media flows to prioritize.
– The eP-CSCF is located in the Home IMS domain of the IMS Public User Identity being registered via the eP-CSCF.
– The WIC may have no way to access the content of an ISIM/USIM on the UE
U.1.2 Architecture and reference model
Figure U.1.2-1 shows the WebRTC IMS architecture. The WWSF (WebRTC Web Server Function) is located either within the operator network or within a third party network and is the web server contacted by the user agent (generally after clicking on a link or entering a URL into the browser). The P-CSCF enhanced for WebRTC (eP‑CSCF) is the endpoint for the signalling connection from the client and is located in the operator network.
NOTE 1: The presence of dashed elements in the figure depends on the configuration.
PCC functional elements are present only for EPC access with QoS.
The corresponding PCC elements for fixed access are also optionally supported but not shown.
The NAT in figure U.1.2-1 is meant for non-cellular access to IMS.
Figure U.1.2-1: WebRTC IMS architecture and reference model
NOTE 2: W3 corresponds to the output of the IETF RTCWEB discussions.
NOTE 3: The enhanced network entities, such as the eP-CSCF, might be decomposed into multiple network elements (e.g. P-CSCF and WebRTC Signalling Function) in future Releases to address additional use cases and configurations.
NOTE 4: The W5 reference point is an optional signalling interface between the WAF and the eP-CSCF. The W5 reference point is not specified and is implementation specific.
U.1.3 Functional entities
U.1.3.1 WIC (WebRTC IMS Client)
A WebRTC IMS Client (WIC) is an application using the WebRTC extensions specified in WebRTC 1.0 [85] except for those extensions specifically exempted by 3GPP specifications (e.g. TS 26.114 [76]) and providing access to IMS by interoperating with the WebRTC IMS access architecture defined in this Annex.
Any IP access network with access to the internet may be used by a WIC; nevertheless WebRTC traffic is subject to the QoS and reachability limitations of this access network.
U.1.3.2 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 user. The WWSF has the following characteristics and functions:
– The WWSF is located either in the operator network or a third party network
– The WWSF provides the Web page presenting the user interface to the user for IMS access.
– The WWSF provides the JS WIC application for downloading to the browser on the UE.
– The WWSF manages the allocation of authorized IMS identities to WICs. The JS application downloaded from the WWSF controls which authentication method applies.
NOTE 1: The WWSF represents a collection of functions that might be further split across servers or networks, so long as they behave in the aggregate as described in this Annex U.
NOTE 2: The WWSF can include WAF functionality in the case WWSF and WAF are in the same domain.
U.1.3.3 eP-CSCF (P-CSCF enhanced for WebRTC)
The P-CSCF enhanced for WebRTC (eP-CSCF) is a P-CSCF including the IMS-ALG functionality and with the following additional functions:
– The eP-CSCF shall support at least one WebRTC IMS client-to-network signalling protocol, e.g. SIP over WebSocket, REST/HTTP based interface, XMPP over WebSocket, etc.
NOTE 1: Other application protocols, alternative message body formats such as JSON and alternatives to WebSocket transport are also not precluded.
– The eP-CSCF provides interworking between W2 and Mw.
– The eP-CSCF verifies that the UE is executing a WIC from an authorized WWSF.
– In the case of WIC registration of individual Public User Identity using IMS Authentication, the eP-CSCF shall relay the IMS authentication and registration information between W2 and Mw.
– Otherwise, i.e. for users authorized by the WWSF or WAF:
– The eP-CSCF shall verify any UE authorization information received from the WIC;
– The eP-CSCF shall verify that the WWSF is authorized to allocate IMS identities;
NOTE 2: For this purpose the eP-CSCF can identify an existing trust relationship between the eP-CSCF and the WWSF or WAF.
– The eP-CSCF shall perform Trusted Node Authentication (TNA) in IMS, as defined in TS 33.203 [19].
– The eP-CSCF shall control the media plane interworking functions provided by the eIMS-AGW, including those additional media plane functions specific to WebRTC.
– The eP-CSCF shall ensure via signalling that RTP streams are not multiplexed ("bundled") onto the same port.
– The eP-CSCF shall negotiate via signalling whether RTP and RTCP flows of an RTP stream are multiplexed onto the same port and shall configure the eIMS-AGW to (de)multiplex such flows if entities anchoring the session media path in the IMS domain do not support that capability.
– The eP-CSCF is located in the domain of the operator that provides the WWSF or with which the WWSF has a service level agreement.
U.1.3.4 eIMS-AGW (IMS Access GateWay enhanced for WebRTC)
The IMS-AGW enhanced for WebRTC (eIMS-AGW) is a standard IMS-AGW with the following additional mandatory characteristics and functions:
– The eIMS-AGW shall support the media plane interworking extensions as needed for WICs.
– The eIMS-AGW shall reside in the same network as the eP-CSCF.
– The eIMS-AGW shall support media security of type "e2ae" (as specified in TS 33.328 [83]) for media protocols specific to WebRTC, including media consent, and DTLS-SRTP as key exchange mechanism for media components using SRTP.
– The eIMS-AGW shall provide NAT traversal support including ICE
– The eIMS-AGW may be used to perform any transcoding needed for audio and video codecs supported by the browser.
– When GTT service is required, the eIMS-AGW shall perform transport level interworking between T.140 [87] over Data Channels and other T.140 transport options supported by IMS.
– When MSRP is transported over the data channel, the eIMS-AGW shall act as an MSRP B2BUA between MSRP over Data Channels and the other MSRP transport options supported by IMS.
NOTE: If CEMA extensions for transport-level interworking for MSRP are supported in IMS, the eIMS-AGW will also support this option.
– When BFCP service is required for conference floor control and BFCP is transported over Data Channels, the eIMS-AGW shall perform transport level interworking between BFCP over Data Channels and other BFCP transport options supported by IMS.
– The eIMS-AGW shall support the media plane optimization for WICs.
– The eIMS-AGW shall support that RTP and RTCP flows of an RTP stream between WIC and eIMS-AGW are multiplexed onto the same port, and shall support de-multiplexing such RTP and RTCP flows toward the core network.
U.1.3.5 WAF (WebRTC Authorisation Function)
The WebRTC Authorisation Function (WAF) has the following characteristics and functions:
– The WAF shall issue the authorisation token to WWSF.
– The WAF may either authenticate the user itself as part of the token issuance process, or it trusts the user identity provided by the WWSF.
– The WAF may either reside in the operator domain or the third party domain.
The WAF is not used in the case of IMS registration scenario using IMS Authentication, described in clause U.2.1.1.
NOTE: The WWSF can include WAF functionality in the case WWSF and WAF are in the same domain.
U.1.4 Reference points
U.1.4.1 W1 (UE to WWSF)
The W1 reference point is between the UE and the WWSF. The HTTPS protocol is normally used to access the web page providing the User Interface for the WIC and to download the WIC JS application to the browser.
U.1.4.2 W2 (UE to eP-CSCF)
The W2 reference point is the signalling interface between the UE and the eP-CSCF. SIP over secure WebSocket is a non-mandatory option for W2 in Release 12, where the SIP/SDP procedures are based on Gm with enhancements to support extensions defined for WIC, and secure WebSocket is the supported transport protocol. Other protocols are allowed on W2 for WebRTC access but are not described in this document.
U.1.4.3 Iq (eP-CSCF to eIMS-AGW)
The Iq reference point is between the eP-CSCF and eIMS-AGW and is enhanced to control the additional bearer plane functions specific to WIC.
U.1.4.4 W3 (UE to eIMS-AGW)
The W3 reference point is between the UE and eIMS-AGW. W3 carries the user plane between the UE and the network (see clause U.1.5).
U.1.4.5 W4 (WWSF to WAF)
The W4 reference point is the signalling interface between the WWSF and the WAF. The WWSF obtains an authorisation token from the WAF from which the user’s identities, identities of WWSF and WAF, and a lifetime may be derived in the case of IMS registration scenarios based on web authentication and assignment from a pool of user identities.
U.1.5 Media plane protocol architecture
U.1.5.0 General
The IMS AGW enhanced for WebRTC (eIMS-AGW) is the media plane interworking element with the functions described in clause U.1.3.4.
NOTE: In this clause, the figures describe the end to end scenario where "the peer" corresponds to a remote IMS terminal. In this case, when e2ae security is needed, TS 33.328 [83] shall govern the interaction between "the peer" and the IMS-AGW that serves it. Other scenarios with other kind of peers (e.g. the peer is another webRTC terminal) are possible but not represented.
U.1.5.1 Protocol architecture for MSRP
Figure U.1.5.1-1 shows the protocol architecture for support of MSRP, when transported over the data channel, from a WebRTC IMS client (WIC).
When MSRP is transported over the data channel, the eIMS-AGW shall provide either a transport relay function from Data Channel to TCP or an MSRP B2BUA to allow interoperation with existing MSRP peer endpoints.
UDP transport of DTLS shall be supported and TCP transport of DTLS may be supported to enable traversal of UDP-blocking NATs/firewalls.
Figure U.1.5.1-1: Protocol architecture for MSRP
Figure U.1.5.1-2: Protocol architecture for MSRP acting as transport relay function
U.1.5.2 Protocol architecture for BFCP
Figure U.1.5.2-1 shows the protocol architecture for support of BFCP, when transported over the data channel for conference floor control, from a WebRTC IMS client (WIC).
When BFCP service is required for conference floor control and BFCP is transported over Data Channels, the eIMS-AGW shall provide a transport relay function from Data Channel to TCP to allow interoperation with existing BFCP peer endpoints.
UDP transport of DTLS shall be supported and TCP transport of DTLS may be supported to enable traversal of UDP-blocking NATs/firewalls.
Figure U.1.5.2-1: Protocol architecture for BFCP
U.1.5.3 Protocol architecture for T.140
Figure U.1.5.3-1 shows the protocol architecture for support of T.140 from a WebRTC IMS client (WIC).
The eIMS-AGW shall provide a transport relay function from Data Channel to RTP to allow interoperation with existing T.140 peer endpoints.
UDP transport of DTLS shall be supported and TCP transport of DTLS may be supported to enable traversal of UDP-blocking NATs/firewalls.
Figure U.1.5.3-1: Protocol architecture for T.140
U.1.5.4 Protocol architecture for Voice and Video
Figure U.1.5.4-1 shows the protocol architecture for support of Voice and Video from a WebRTC IMS client (WIC). Transcoding (i.e. allowing codec1 to be different from codec2) is optional. SRTP between the UE and the eIMS-AGW relies on keying material negotiated via DTLS.
NOTE 1: Transcoding at the eIMS-AGW may apply to none, one or both of the voice and video components
Figure U.1.5.4-1: Protocol architecture for Voice and Video
NOTE 2: RFC 4571 [90] framing is used for RTP streams transferred over TCP. RTP over TCP may be used when NATs/Firewalls perform UDP blocking.