Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

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.
Up

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]
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)".
Up

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.
3GPP
Third Generation Partnership Project
AF
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
IP
Internet Protocol
IP-CAN
IP-Connectivity Access Network
I-CSCF
Interrogating CSCF
JS
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
Up

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.
Up

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

Up   Top   ToC