Tech-invite3GPPspaceIETF RFCsSIP

Content for  TR 23.701  Word version:  12.0.0

Top   Top   None   None   Next
1…   5…


1  ScopeWord‑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.
    • 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

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.
TR 21.905: "Vocabulary for 3GPP Specifications".
TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".
draft-ietf-rtcweb-jsep-03:  "Javascript Session Establishment Protocol".
draft-ietf-sipcore-sip-websocket-09:  "WebSocket as a Transport for SIP".
OMA Work Item 0284: "RESTful Network API for VVoIP".
draft-ietf-mmusic-sdp-bundle-negotiation-04:  "Multiplexing Negotiation Using Session .Description Protocol (SDP) Port Numbers".
RFC 5761:  "Multiplexing RTP Data and Control Packets on a Single Port".
draft-ivov-mmusic-trickle-ice-01.  "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol".
TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
draft-ietf-avtcore-rtp-circuit-breakers-02:  "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions".
draft-muthu-behave-consent-freshness-03:  "STUN Usage for Consent Freshness".
RFC 5763:  "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)".
TS 22.228: "Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); Stage 1".
TS 33.203: "3G security; Access security for IP-based services".
RFC 6714:  "Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)".
RFC 5389:  "Session Traversal Utilities for NAT (STUN)".

3  AbbreviationsWord‑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.
Third Generation Partnership Project
Application Function
Application Programming Interface
Access Point Name
Binary Floor Control Protocol
Connection Establishment for Media Anchoring
Call State Control Function
Datagram Transport Layer Security
Datagram Transport Layer Security SRTP
IMS-AGW enhanced for WebRTC
P-CSCF enhanced for WebRTC
Evolved Packet Core
Interface between the WebRTC client and the WebRTC Signalling Function
Interface between the WebRTC client and the WebRTC Media Function
Global Text Telephony
Home Subscriber Server
Interactive Connectivity Establishment
Internet Engineering Task Force
IP Multimedia Subsystem
Internet Protocol
IP-Connectivity Access Network
Interrogating CSCF
Javascript Session
Javascript Session Establishment Protocol
JavaScript Object Notation
Local Breakout
Message Session Relay Protocol
Network Address Translation
Proxy CSCF
Policy Control and Charging
Policy and Charging Enforcement Function
Policy and Charging Rules Function
Quality of Service
Rich Communication Suite
Representational State Transfer
Request for Comments
Real-time Transport Protocol
Serving CSCF
Session Description Protocol
Session Initiation Protocol
Secure RTP
Transport Layer Security
Trusted Network Access
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
WebRTC IMS Client
WebRTC Web Server Function
Extensible Messaging and Presence Protocol

4  Assumptions and architectural requirementsWord‑p. 9

4.1  Assumptions

  • 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.
  • 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.
    • 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 requirementsWord‑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:

Up   Top   ToC