Content for TR 23.701 Word version: 12.0.0

...

1 Scope p. 7

The present document contains a study on the potential modifications of the IMS architecture and stage 2 procedures as required by the support of Web Real Time Communication (WebRTC) clients access to IMS.

For this purpose the present document addresses (non exhaustive list):

Architectural impacts for the support of different kinds of clients (operator / Third party) in different scenarios.
The architecture (including the support of WebRTC clients access to IMS for clients on a 3GPP UE that are roaming at access level) for following scenarios:
- when 3GPP or non-3GPP access is used (common IMS).
- when the UE is not roaming at access level or when home-routed access is used (these scenarios have priority for the work).
- evaluate/study whether IMS roaming architecture is used in case of 3GPP LBO.
Media plane aspects e.g.:
- architectural impacts related to the use of specific codecs: the study addresses transcoding aspects but also the case where the use of 3GPP codecs is possible from the UE.
  
  NOTE:
  How a WebRTC client / the browser can access to 3GPP codecs on the UE is out of the SA WG2 study scope.
- architectural impacts related to media plane security interworking.
Authentication and Control plane security related aspects.
Charging.
PCC aspects.
Usage of the 3GPP Packet Core Network to support WebRTC clients access to IMS.

For example the following points had been studied: the PDN connection / PDP context to be used by WebRTC traffic especially in roaming cases and the QoS control, e.g. how a WebRTC client can use the QoS supported / delivered by the 3GPP Packet Core.

2 References p. 7

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]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".

[3]

draft-ietf-rtcweb-jsep-03: "Javascript Session Establishment Protocol".

[4]

draft-ietf-sipcore-sip-websocket-09: "WebSocket as a Transport for SIP".

[5]

OMA Work Item 0284: "RESTful Network API for VVoIP".

[6]

draft-ietf-mmusic-sdp-bundle-negotiation-04: "Multiplexing Negotiation Using Session .Description Protocol (SDP) Port Numbers".

[7]

RFC 5761: "Multiplexing RTP Data and Control Packets on a Single Port".

[8]

draft-ivov-mmusic-trickle-ice-01. "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol".

[9]

TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".

[10]

draft-ietf-avtcore-rtp-circuit-breakers-02: "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions".

[11]

draft-muthu-behave-consent-freshness-03: "STUN Usage for Consent Freshness".

[12]

RFC 5763: "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)".

[13]

TS 22.228: "Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); Stage 1".

[14]

TS 33.203: "3G security; Access security for IP-based services".

[15]

RFC 6714: "Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)".

[16]

RFC 5389: "Session Traversal Utilities for NAT (STUN)".

3 Abbreviations p. 8

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

3GPP

Third Generation Partnership Project

Application Function

API

Application Programming Interface

APN

Access Point Name

BFCP

Binary Floor Control Protocol

CEMA

Connection Establishment for Media Anchoring

CSCF

Call State Control Function

DTLS

Datagram Transport Layer Security

DTLS-SRTP

Datagram Transport Layer Security SRTP

eIMS-AGW

IMS-AGW enhanced for WebRTC

eP-CSCF

P-CSCF enhanced for WebRTC

EPC

Evolved Packet Core

Gwebrtc

Interface between the WebRTC client and the WebRTC Signalling Function

Gwebrtcm

Interface between the WebRTC client and the WebRTC Media Function

GTT

Global Text Telephony

HSS

Home Subscriber Server

ICE

Interactive Connectivity Establishment

IETF

Internet Engineering Task Force

IMS

IP Multimedia Subsystem

Internet Protocol

IP-CAN

IP-Connectivity Access Network

I-CSCF

Interrogating CSCF

Javascript Session

JSEP

Javascript Session Establishment Protocol

JSON

JavaScript Object Notation

LBO

Local Breakout

MSRP

Message Session Relay Protocol

NAT

Network Address Translation

P-CSCF

Proxy CSCF

PCC

Policy Control and Charging

PCEF

Policy and Charging Enforcement Function

PCRF

Policy and Charging Rules Function

QoS

Quality of Service

RCS

Rich Communication Suite

REST

Representational State Transfer

RFC

Request for Comments

RTP

Real-time Transport Protocol

S-CSCF

Serving CSCF

SDP

Session Description Protocol

SIP

Session Initiation Protocol

SRTP

Secure RTP

TLS

Transport Layer Security

TNA

Trusted Network Access

WebRTC

Web Real-Time Communication

WebRTC Signalling Function

Mediation function between a WebRTC client and IMS for the control plane

WebRTC Media Function

Mediation function between WebRTC client and IMS for the media plane

WIC

WebRTC IMS Client

WWSF

WebRTC Web Server Function

XMPP

Extensible Messaging and Presence Protocol

4 Assumptions and architectural requirements p. 9

4.1 Assumptions p. 9

SDP offer/answer exchange is the mechanism used for media plane feature negotiation.
In this release, the architecture does not support media multiplexing that is defined for WebRTC clients.
NOTE 1:
A JS downloaded in a WIC accessing to IMS services is not expected to allow usage of media multiplexing in the browser. If an SDP offer with media multiplexing was nevertheless sent to the network the part of the SDP offer associated with media multiplexing would be removed at the entry of the IMS network.
In this release, WebRTC specific media plane extensions will be handled at the access edge and will not be propagated to other IMS functions.
In this release, in case of a network based interworking between WebRTC and IMS, for 3GPP and EPC access from a WebRTC client:
- There is no assumption on the APN being used by the WebRTC client, e.g. the signalling sent by the WebRTC client may use the same APN than the one used for plain Internet service.
- Subject to inter-operator agreement and appropriate network configuration, EPC/GPRS roaming is supported for WebRTC client access using any available APN. Either LBO or home routing can be used subject to reachability.
- Use of available techniques to select preferred access technologies and APNs, and to provide IP address continuity, are allowed but not described.
- When the WebRTC client is served by an IP-CAN in a configuration that supports PCC, it shall be possible to request QoS within the IP-CAN for WebRTC media.
  
  NOTE 2:
  To ensure full end to end QoS support, proper IP forwarding policies should be set in the path between the PGW 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.

4.2 Architectural requirements p. 10

The architecture shall fulfil the following requirements:

WebRTC clients shall have access to the IMS through one or more mediation function(s) for signalling and media.
The later normative work on WebRTC shall support WebRTC client access to the following media protocols (in addition to audio and video): MSRP, BFCP and T.140.

The following requirements for the signalling plane between WebRTC and IMS are defined:

The architecture shall support control plane interworking procedures between a WebRTC client and IMS.
The architecture shall support negotiation to ensure that RTP streams are not multiplexed onto the same port if entities anchoring the session media path in the IMS domain do not support that capability.
The architecture shall support negotiation to ensure that RTP and RTCP flows of an RTP stream are not multiplexed onto the same port if entities anchoring the session media path in the IMS domain do not support that capability.
The architecture shall support negotiation of media plane interworking between WebRTC and IMS.
The architecture shall support negotiation of ICE procedures towards the WebRTC client to enable connectivity checks for establishing the media path.

The following requirements for the media plane between WebRTC and IMS are defined:

The architecture shall support transcoding that may be required for audio and video traffic.
The architecture shall support any necessary interworking between media plane security mechanisms provided by WebRTC and IMS.
The architecture may support (de)multiplexing of RTP and RTCP flows onto the same port.
The architecture shall support STUN for ICE connectivity checking.
The architecture shall support STUN for the WebRTC "consent freshness" feature.

The architecture shall fulfil the following PCC related impacts for WebRTC media transport: