Printed by Jouve, 75001 PARIS (FR)

(19)E

P3

007

401

A1

TEPZZ¥ZZ74Z_A_T(11) EP 3 007 401 A1

(12) EUROPEAN PATENT APPLICATION

(43) Date of publication: 13.04.2016 Bulletin 2016/15

(21) Application number: 14188078.1

(22) Date of filing: 08.10.2014

(51) Int Cl.:H04L 29/06 (2006.01)

(84) Designated Contracting States: AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TRDesignated Extension States: BA ME

(71) Applicant: Deutsche Telekom AG53113 Bonn (DE)

(72) Inventors: • Sivchenko, Dmitry

64331 Weiterstadt (DE)

• Maruschke, Michael04275 Leipzig (DE)

• Zimmermann, Jens64372 Ober-Ramstadt (DE)

(74) Representative: Braun-Dullaeus Pannen Patent- und RechtsanwältePlatz der Ideen 240476 Düsseldorf (DE)

(54) Integration of WebRTC based clients into IMS without SIP Registration

(57) Method for integrating of a WebRTC client intoa Multimedia Subsystem ("IMS") comprising a corre-sponding WebRTC Application Server ("WAS") is imple-

mented into the IMS core as an Application Server whichhas a direct access to the Home Subscriber Server("HSS").

EP 3 007 401 A1

2

5

10

15

20

25

30

35

40

45

50

55

Description

Field of the invention:

[0001] The invention relates to a method and systemfor efficient integration of Web Real Time Communication("WebRTC") based clients into IP Multimedia Subsystem("IMS").

Description of the prior art:

[0002] The SIP (Session Initiation Protocol) based IMSis the basic session control system used by telecommu-nication operators to provide their multimedia communi-cation services like voice/telephony to customers in IPbased networks. In order to use IMS services an IMS ora SIP client must be installed on the user device, eitherbuilt into the operating system of the device by default orinstalled separately by the user. For the integration ofanalogue and/or Integrated Services Digital Network("ISDN") telephones into the IMS based infrastructure,various gateway devices are used offering analogueand/or ISDN typically interfaces for the connection of enddevices and using SIP for signalling and Real TimeTransport Protocol (RTP) for media transport towardsIMS.[0003] IP based devices like computers or smart-phones usually have a separate IMS/SIP client so thatno additional gateways are required. The usage of a sep-arate SIP client on user device is one of the IMS draw-backs. In order to use IMS services signalled through theIMS core network the SIP client must support the uniquedefinite signalling used in the IMS for the session man-agement. That is why SIP is standardised in order to en-able interoperability between different clients and IMScore networks. However, for the introduction of new serv-ices on the basis of IMS, an update of SIP clients is oftennecessary. Continuous updating of IMS clients for differ-ent operating systems and Operation Systems (OS) ver-sions is another challenge for having an add-on signallingclient on the user device.[0004] WebRTC suite has been defined in the initialphase and actively developed (IETF. RtCweb status pag-es. http://tools.ietf.org/wg/rtcweb/ or C. Jennings, A.Narayanan, D. Burnett, and A. Bergkvist, "WebRTC 1.0:Real-time communication between browsers," W3C,W3C Working Draft, 01 July 2014, ht-tp://dev.w3.org/2011/webrtc/editor/ar-chives/20140704/webrtc.html, retrieved: July, 2014).[0005] WebRTC introduces support for multimediacommunication direct from Web Browsers as Chrome,Firefox and Opera. The complete logic of multimedia ap-plication is downloaded to the browser in form of a Java-Script so that no adaptation of additional applications isrequired on the device. Any IP device having a WebRTCcapable Web browser can participate in the communica-tion using WebRTC.[0006] WebRTC does not define any particular signal-

ling protocol. That is why developers can choose the mostappropriate protocol for their special use case. So it ispossible to implement new communication features, fast-er. In this sense, WebRTC enables new architecturesand protocols for the control/signalling plane.[0007] For the consumer it would be meaningful tocommunicate from a WebRTC based browser device toany other existing legacy Voice- and Video-Telephonydevices like 2G or 3G mobile phones or analogue/ISDNtelephones or SIP User Agents. Therefore, the interop-erability of WebRTC clients with IMS is necessary to en-able communication between WebRTC and IMS/PSTNusers. The current architecture for the integration of We-bRTC clients to IMS is defined in 3GPP TS 23.228V12.5.0 Annex U (2014-06).[0008] In that prior art, Register Signalling messagesinvoke processing of almost all components within IMScore. In real carrier-grade IMS installations with millionsof registered subscribers the traffic load generated bySIP Register messages can reach up to 95% of the com-plete IMS signalling capacity. IMS components musttherefore be planned and dimensioned mainly forprocessing of SIP registration traffic not only from legacySIP devices, but also from WebRTC clients connectedto the IMS using this prior art approach. By doing that,the capacity of IMS components involved in Register sig-nalling procedures must be doubled in the worst case.That has a dramatic impact on the economics of IMSdeployments, the performance of the IMS platform incase of fluctuating subscriber numbers and the flexibilityof the whole IMS core in the case that the registrationtimers are changed (firstly decreased) or more subscrib-ers must be served.

Object of the invention:

[0009] The object of the present invention is to providea method and a system for integrating WebRTC basedclients into IMS alternative to standardized solution andwith a reduced traffic load produced by SIP Register sig-nalling messages.

Summary of the invention:

[0010] The invention concerns a method and a systemfor the integration of WebRTC clients into a MultimediaSubsystem ("IMS") by implementing a new WebRTC Ap-plication Server ("WAS") into the IMS core. This newWAS has an access to the respective subscriber register,especially to the Home Subscriber Server ("HSS"). Theinvention comprises the steps: WebRTC client registerswith the WAS using a protocol applying IMS credentialsdue to access of WAS to the subscriber registers espe-cially the HSS. Further WAS modifies initial Filter Criteria("iFC") by entering itself to the iFC set in the HSS uponsuccessful registration of WebRTC client with the WASand by deleting itself from the iFC set in the HSS uponcustomer deregistration.

1 2

EP 3 007 401 A1

3

5

10

15

20

25

30

35

40

45

50

55

[0011] By this, SIP register procedure is not necessaryfor registration of WebRTC clients with IMS core.[0012] The WAS enters itself into iFC for relevant SIPmessages the operator want to forward also to WebRTCclients (e.g. INVITE, MESSAGE, INFO, etc.) for sessioncases terminating registered as well as terminating un-registered. That is necessary to send the message to theWAS independently whether another SIP clients of thesubscriber with the same telephone number used on theWebRTC client are registered with IMS or not.[0013] A WebRTC-based Web application is definedas a full IMS endpoint with which the user logs on to thenetwork and can interact with this. In order to realize acommunication with the IMS, the WAS must provide theISC interface. Call signalling is passed between We-bRTC clients and traditional IMS terminals via the WAS.To receive call signalling as a WebRTC client, corre-sponding iFCs, must be defined. For interconnection tothe media level with traditional IMS terminals, standard-ized components such as the eIMS-AGW will be used.A special feature of the invention is that the users of We-bRTC clients can use their traditional IMS IDs.[0014] With the inventive method QoS and emergencyfunctions can be realised. The AS is arranged within atraditional IMS and has the necessary function blocks toensure these functionalities. The requirement of load ef-ficiency is guaranteed. It does not necessarily require anIMS registration of WebRTC clients, but can occur viaother mechanisms. When IMS registration is omitted,there are no re-registration procedures which generatemost of the load in traditional telephone networks.[0015] A significant advantage of the inventive conceptis that WebRTC is offered as an additional alternative foraudio and video communication in an IMS. In this no IMSregistration needs to be performed. Users can re-usetheir user-specific credentials which are already created.It is therefore effective to integrate WebRTC based cli-ents in an IMS -based infrastructure.[0016] By this the invention introduces a new methodand system for the integration of WebRTC based clientsinto IMS without usage of SIP register messages. By us-ing the proposed method all IMS services available forWebRTC clients integrated with IMS using legacy meth-od are still available while WebRTC clients do not gen-erate any additional SIP Register traffic load in the IMSnetwork.

Brief description of the drawings:

[0017]

Figure 1 shows the connection of WebRTC clients toIMS as currently defined in prior art,

Figure 2 discloses a proposed connection of We-bRTC clients to the IMS and

Figure 3 illustrates the internal architecture of the pro-

posed WebRTC Application Server (WAS).

Figure 4 Registration of a WC.

Figure 5 Signalisation for an incoming call.

Figure 6 Signalisation for an outgoing call.

Detailed description of a preferred embodiment:

[0018] Figure 1 shows the prior art WebRTC IMS ar-chitecture. This WebRTC IMS architecture is explainedin TS 23.228 (especially in V 12.5.0) Annex U. TheWWSF (WebRTC Web Server Function) is located eitherwithin the operator network or within a third party networkand is the web server contacted by the user agent. Fol-lowing the components are explained:[0019] The UE (User Equipment) is a terminal with aWebRTC enabled browser. The UE must have an IP con-nectivity to be able to download a client application froma WWSF. The UE does not have mandatory IMS func-tions, but may communicate with the network via thestandard Gm interface by implementing appropriatefunctions.[0020] A WebRTC IMS client (WIC) is a WebRTCJavaScript application that has all the features to interactwith the architecture shown in figure 1. WIK is an appli-cation using the WebRTC extensions specified in thestandard and providing access to the IMS network basedarchitecture. The WIC is integrated part of the UserEquipement (UE) in this standardized proposal. The ap-plication is downloaded from a WWSF and executed ina WebRTC enabled browser or an adequate JavaScriptexecution environment on the UE. The WIC shall supportall the typical IMS functionalities. It shall be able to useWeb authentication in addition to the standardized IMSregistration and authentication.[0021] The WebRTC Web Server Function (WWSF) isthe initial point of contact for the user. It provides a webpage, which is the user interface (UI) for the user.[0022] Furthermore, the WWSF makes the JavaScriptWIC application available which may be downloaded andexecuted by the web browser on the UE.[0023] The enhanced Proxy Call Session ControlFunction (eP-CSCF) is the endpoint for the signallingconnection from the client and is located in the operatornetwork. It is a P-CSCF according to the 3GPP TS 23.228specification with extensions for WebRTC. The eP-CSCF should support at least a common signalling var-iant. This can be among other SIP or XMPP over Web-Socket. For this proxy server must perform a transcriptionfrom W2 to Mw interface. Besides this eP- CSCF shouldcontrol the media data conversion functions that are pro-vided by the eIMS-AGW.[0024] By using current approach the client performsregistration with the IMS core via W2 interface by usingits identity either using SIP over WebSocket or by usingother proprietary signalling that is converted to SIP in an

3 4

EP 3 007 401 A1

4

5

10

15

20

25

30

35

40

45

50

55

intermediate gateway (separate or collocated with theenhanced P-CSCF). SIP Register Messages are usedlatest on Mw interface in the IMS core to register theWebRTC user as a regular IMS subscriber.[0025] The eIMS-AGW is a standard IMS-AGW whichhas been extended for WebRTC. Media data are ex-changed between UE and eIMS-AGW that convertssRTP (secure Real Time Transport Protocol) used in We-bRTC to RTP used in IMS over W3 interface. The AGWshall support the media data extensions that are used inWebRTC. Since interoperability between WebRTC -based clients and traditional IMS clients is not possiblewithout converter, is this component of great importance.WebRTC-based clients mandatory use SRTP for datatransfer, which is not supported by traditional IMS termi-nals. Therefore it must support DTLS-SRTP as the ex-change mechanism as well as the SRTP. Even the AGWmust provide functions for overcoming NAT which mainlyinvolve the ICE mechanisms. The elMS AGW should alsoact as a transcoder and support the common WebRTCcodecs. Therefore the eIMS-AGW must act as full We-bRTC counterpart.[0026] The WebRTC Authorisation Function (WAF) isused to authenticate the user for downloading the Webpage from WWSF. It creates an authentication token forthe user and deliver it to the WWSF. This function canthereby authenticate the user in the token creation proc-ess or she trusts the user identity that it has receivedfrom the WWSF.[0027] The WebRTC IMS architecture supports differ-ent IMS registration scenarios that may differ in the au-thentication method, and ownership of the WWSF (i.e.operator network or third party). After initial registrationthe client generate SIP Re-registration messages ac-cording to the Expire timer configured in the IMS core.Latest after eP-CSCF SIP Register messages are usedfor this process. Periodic application level re-registrationis initiated by the UE either to refresh an existing regis-tration or in response to a change in the registration statusof the UE (TS 23.228, clause 5.2.2.4).[0028] Besides, in figure 1 the shortcut "NAT" meansNetwork Address Translation, "IP-CAN" is the IP-Con-nectivity Access Network and PCEF the Policy andCharging Enforcement Function. PCRF is the PolicyControl Rule Function.[0029] The W1 interface is located between the UEand the WWSF. The protocol to be used for this referencepoint is the HTTPS protocol to access the website anddownload the WIC JavaScript application[0030] The W2 reference point is located between theUE and eP-CSCF. A protocol to be used is not definedbut the favourite is SIP transmitted over a WebSocketconnection. The new approach uses a W2* referencepoint between UE and the inventive WAS.[0031] W3 is the reference point between the UE andthe eIMS-AGW. Media data are transmitted via this in-terface. Also the key exchange for SRTP using DTLSand signalling is done via this interface to overcome NAT

using STUN.[0032] W4 is the signalling interface between theWWSF and WAF. Via this reference point the WWSFgets a authorising token from WAF which confirms theidentity of the user.[0033] The W5 reference point is an optional signallinginterface between the WAF and eP-CSCF.[0034] The Iq* interface is located between the eP-CSCF and the eIMS-AGW. This reference point was ex-tended to control the additional media transfer functionswhich are specific for WebRTC.[0035] The architecture shown in figure 1 supports dif-ferent scenarios for registration which differ in their meth-od of authentication. One scenario is the IMS authenti-cation another scenario is the Web authentication. Bothare explained in TS 23.228.[0036] For reducing the traffic of signalling messagesit is proposed to connect the WebRTC Application Serverserving WebRTC customers by using ISC interface asan additional IMS application server that will supersedethe need of SIP Register messages in IMS core network.Figure 2 shows the proposed integration of WebRTCclients to the IMS compared to the actual architecturefollowed by the WebRTC and IMS community.[0037] The usage of WWSF and W1 interface is notmodified in the proposal and is used to download JavaScript with the WebRTC application that will run on theclient.[0038] The WebRTC client (WC) is a WebRTC Java-Script application that implements all the functions to in-teract with the architecture that is running on a WebRTC-enabled device. The WC is a combination of applicationand hardware. The application is downloaded it from aWWSF and running on the WebRTC-enabled device oran adequate JavaScript execution environment. The We-bRTC-enabled terminal is a terminal which provides aWebRTC-enabled web browser. In contrast to the WICthe WC dispenses with an IMS registration. There is onlyan identity check of the user based on the user-specificcredentials.[0039] The invention proposes an additional WebRTCApplication Server (WAS) that the link between WC andthe IMS network. The WAS has a WebRTC signalingfunction for connection with the WCs. The WAS is con-nected to the S-CSCF in IMS with ISC interface (and/orto the I-CSCF using Ma interface). By this, eP-CSCF isnot longer used for the signalling with WebRTC users.SIP Register messages are not used in the IMS core forWebRTC users as well. Figure 3 shows the architectureof the proposed WebRTC Application Server.[0040] The new WAS implements functions of a legacyIMS Application Servers so that it has a "read/write"- ac-cess over the Sh interface to the HSS database withstores user profiles.[0041] In order to enable Quality of Service (QoS) forWebRTC clients, the IMS Application Function (AF) isimplemented in the WAS. Interaction with the Policy Con-trol Rule Function (PCRF) for resource management in

5 6

EP 3 007 401 A1

5

5

10

15

20

25

30

35

40

45

50

55

the transport network is available for WAS via Rx inter-face. For media handling with Access-Border GatewayFunctions (A-BGF) the WAS implements the H.248 pro-tocol based Iq* interface to the existing eIMS-AGW. Al-ternatively, the WAS can introduce or co-locate any ownmedia handling function in order to control and convertthe payload traffic transported with sRTP in WebRTCand RTP in IMS. The Iq* interface is an internal interfacesin this case. Additional media processing functions -eIMS-AGW must then be implemented/co-located in theWAS. By doing that W3 interface is then between UEand eIMS-AGW implemented/co-located in the WAS,that follows the same path in the network as W2* inter-face. Other additional interfaces typically available onIMS Application Servers can be implemented on theWAS - for example Rf for accounting or X1/X2/X3 forLawful Interception.[0042] The two function blocks are controlled by theWebRTC Application Server Control Function (WASCF).This WASCF passes messages between the two functionblocks, performs identity verification of registered usersand controls the handlers for database access, QoS andmedia conversion.[0043] For user authentication and signalling betweenWAS and WebRTC client any protocol on W2* interfacecan be used. Via the W2* interface the signalling mes-sages for call setup or the like can be transferred. A pro-tocol used is not defined for this interface. It notes thatafter the successful connection between WC and WHAT,user identity information is transferred.[0044] Since WAS has access to the HSS via the Shinterface, it has access to IMS user credentials. The We-bRTC client can therewith be authenticated on the WASby using its IMS credentials. The authorisation processis not limited to this method and any other authenticationmethod can be used on W2* (e.g. OpenID or similar).[0045] To verify the identity of the user who has estab-lished a connection with the WAS, the WAS reads thecredentials from the central HSS database. If the We-bRTC signaling function receives a message, it is for-warded to the WASCF which in turn activates the appro-priate handler of the IMS AS function.[0046] The information received is delivered to WAS-CF to perform a verification of the user. After successfulverification the WAS updates the service profile of theuser. For that the WASCF again controls the appropriatehandler in the IMS AS Function and provides the serviceprofiles. In this service profiles the iFC and the triggerpoint is stored so that future calls will be routed to thatWAS. If the WebRTC connection is lost or a user termi-nates the connection the iFC is disabled again. If a callis dropped or obtained WASCF controls the appropriatehandler for QoS and the media conversion and performsconversion of the message interface W2* to the ISC in-terface and vice versa. To allow access to user-specificinformation located in the HSS, the WAS must be locatedin the network of the operator and should not be providedby a third party.

[0047] In result of the authentication process the WASknows the IMS Public User Identity (IMPU) of the We-bRTC user. By using Sh interface the WAS enters itselfinto the initial filter criteria (iFC) set associated with theIMPU. The WAS is triggered by all incoming messagesto IMPU in both cases, where IMPU is registered usingthe legacy SIP registration procedures but also if no SIPregistration has been performed in IMS for IMPU. In thisway all incoming calls (destined to this known IMPU) afteriFC modification will be delivered to the WAS independ-ently whether IMPU is registered in IMS using SIP reg-istration procedure or not registered at all.[0048] For incoming calls the WAS forwards the callusing the appropriate protocol on W2* interface to theWebRTC client so that the call can be established. Duringcall establishment the Rx interface from the AF collocatedon the WAS can be used to enable QoS support for themultimedia session being established.[0049] The WAS works as a Forking Proxy (a StatefulSIP Proxy Server), forks signalling messages and entersitself into the SIP Route. The WAS forwards the incomingsession control messages to the WebRTC client and alsosends the relevant SIP signalling messages back to theS-CSCF. The incoming call is then also received on leg-acy IMS terminals registered with the same IMPU by us-ing SIP registration. After receiving answer messagefrom a client (either 200 OK via the IMS core or appro-priate signalling message over W2* interface), the otherleg of the call can be cleared. The SIP method CANCELis used for clients registered with the IMS on the regularway and the appropriate signalling message is used overW2* interface for WebRTC clients.[0050] For outgoing sessions originating from the We-bRTC client the signalling over W2* is converted to theIMS SIP by the WAS and is sent to the IMS core overthe ISC interface from the WAS. Application Function inthe WAS can again be involved in the call setup processin order to enable QoS for the multimedia session.[0051] The keep-alive mechanism over W2* interfaceused to determine the availability of the WebRTC clientis out of scope of this patent application. Efficient lightweb technologies can be used for this purpose, pushnotifications can be used as well. In the case WAS takesthe decision the WebRTC client is not available anymore,WAS deletes itself from the iFC. This procedure is doneover the Sh interface.[0052] Subsequently, the invention is explained withreference to a registration of a user and to the signallingsequence for incoming and outgoing calls. The entitiesin the flow charts have markings that are specified inparentheses after the name of the user. Either a WC ap-plication is used or the term "legacy" specifies that anapplication or device that communicates over the Gminterface with a P - CSCF is used.[0053] In figure 4 the registering of a user using a WCis shown: In step 1 the users of the WC application sendsits private user identifier and a hash value made of user-specific information on the WAS. The WHAT makes a

7 8

EP 3 007 401 A1

6

5

10

15

20

25

30

35

40

45

50

55

request to the database server in order to obtain the hashvalue of the user that is stored. The respective steps 2and 3 are transmitted by standard-compliant messagesover the Sh interface. Upon receipt of the hash value averification step 4 is performed. Are the hash value ofthe user and the hash value from the database are iden-tical, the WebSocket connection is maintained. If theydon’t match the WebSocket connection is disconnectedby WAS with the appropriate WebSocket status code.[0054] If the verification is successful, the user profilefor that user which is also located in the HSS is updatedwhereby the WAS creates an iFC and adds a matchingSPT. The SPT is used for the SIP INVITE method. Withthat all SIP INVITE messages are routed directly to WAS.Furthermore, the WAS adds its own address in the ap-plication server element of the iFC and forwards the iFCto the database server (step 5).[0055] For sending calls from a WC a "service route"is needed. This route includes the address of S-CSCFwhich is responsible for this user. Normally, the "ServiceRoute" send in the "200 OK" following a SIP register mes-sage. However, since this message is omitted, the WASmust retrieve it from the database (step 7 and step 8).After these steps, the WC user is authenticated and canreceive and initiate calls by the registered trigger Point.This concept avoids additional re-registration processesbecause disconnections are detected by the WebSocketconnection. For emergency case the IP address of thecurrent WebSocket connection is used.[0056] During an incoming call the user "Bob" receivesan incoming call at both its WC-based and on his legacyterminal (figure 5). Now the iFCS and the so-called SIPforking is of importance. In steps 1 and 2 a SIP INVITEmessage is generated and sent over a P-CSCF to an S-CSCF. The user "Alice" uses her standard IMS UE andno WebRTC client. If the S-CSCF receives the message,the user profile of that user is checked for whom the mes-sage is intended. In step 3 an examination of the iFCSand the given trigger point occurs. If the called user hasa WC account the service profiles of the WAS has alreadybeen inserted. In step 4 the "INVITE" message is routedto the WAS. In step 5 the WAS forwards the messagevia the WebSocket connection to the WC of the user tobe called.[0057] In step 6 the message is returned to the S-CSCF. This SIP forking has the advantage that the callis not only sent to WC but also to a legacy terminal. Withthat multiple dialogs can be created with just one query.To avoid that the request is not sent again to the WASfor the user to call, the WAS makes entries in the SIPheader fields. Steps 6 through 8 show the routing of themessage to the legacy device. After steps 5 and 8 thecall is parallel on the WC and the legacy device whichring at the same time.[0058] Depending on which device answers the call,the response messages are sent via the WAS to the call-ing user. In steps 9 to 12 the call is accepted by Bob’sWC. Once the message reaches the WAS, a SIP CAN-

CEL message is generated in step 13 and sent to thenon accepting unit. Steps 10 and 13 take place at thesame time. Upon receipt of a CANCEL a correspondingresponse is sent (step 16). Then the terminal which re-ceived the CANCEL generates a message to indicatethe termination of the call (step 19). For this purpose a487 Request Cancelled is sent to the WAS.[0059] Similarly, if a 200 OK received, an ACK mustbe generated and sent to complete the three-way hand-shake. This can be seen in steps 19 to 24. Steps 25through 28 are the response messages to the 200 OK tothe receiving party. Thus, the three-way handshake ofthe SIP has been successfully completed and the trans-mission of media starts. By the entries in the SIP headerfields, the WAS stays in the signalling chain for the com-plete dialogue.[0060] According to figure 6 the user "Alice" calls withher WC-terminal user "Bob", who answers with a legacydevice. In step 1 the initial call setup is sent from the WCto the WAS. Since in this request, the information is miss-ing, where this message has to be routed, the WAS hasto append "Service Route" obtained in the registrationphase. The WAS has to generate a SIP INVITE messageand insert the "Service Route" into the header of the IN-VITE message. Besides the WAS enters his address inthe respective header fields to ensure that the correctrouting path will be used for future messages of the dia-log. In step 2 the WAS forwards the customized messageto the S-CSCF. The S-CSCF balances the service profileof the called user. Steps 3-19 are identical to those in thelogic for an incoming call.Since the call is adopted froma legacy device, in step 13 the WC Cancel message hasto be sent to the WC of user Bob. The sequential orderis corresponding to the three-way handshake, like it isused in SIP.[0061] A checkout of the WC from WAS or an interrup-tion of the WebSocket connection is recognized by theWebSocket protocol. Then WAS has to update the serv-ice profile of the user and disable the trigger point andthe iFC, which is responsible for forwarding the messag-es to the WAS for this user. If no WC is logged on for theuser, the messages may not be sent to the WAS. Thesignalling sequence thus corresponds to a standardizedsequence as defined for the communication in an IMS.

Claims

1. Method for integrating of a WebRTC client into a Mul-timedia Subsystem ("IMS")characterised in thata corresponding WebRTC Application Server("WAS") is implemented into the IMS core as an Ap-plication Server which has a direct access to theHome Subscriber Server ("HSS").

2. Method according to claim 1,characterised in that

9 10

EP 3 007 401 A1

7

5

10

15

20

25

30

35

40

45

50

55

WebRTC client registers with WAS using an protocolapplying IMS credentials due to access of WAS tothe HSS andWAS modifies initial Filter Criteria ("iFC") by enteringitself to the iFC set in the HSS upon successful reg-istration of WebRTC client with the WAS and by de-leting itself from the iFC set in the HSS upon cus-tomer deregistration.

3. Method according to claim 1 or 2,characterised in thatWAS uses a W2* interface for exchanging signallingmessages with the WebRTC client.

4. Method according to one of the preceding claims,characterised in thatWAS uses ISC interface for communication with I/S-CSCF (Interrogating/Serving Call Session ControlFunction).

5. Method according to one of the preceding claims,characterised in that,WAS implements H.248 Iq* interface to control theEnhances IMS Access Gateway ("eIMS-AGW") formedia processing.

6. Method according to one of the preceding claims"characterised in that,WAS alternatively is co-located with the eIMS-AGWfunctionality in the same network entity for mediahandling functions for converting between sRTP andRTP.

7. Method according to one of the preceding claims,characterised by,WAS authenticates WebRTC subscriber using anauthentication mechanism with the result that WASknows the IMPU of the WebRTC user.

8. Method according to one of the preceding claims,characterised by,WAS authenticates WebRTC subscriber using itsIMS credential by utilising Sh interface to HSS.

9. System for executing the method according to oneof the preceding claims,characterised by,a WebRTC client integrated into a Multimedia Sub-system ("IMS") a WebRTC Application Server("WAS") which is implemented into the IMS core asan Application Server with direct access to the HomeSubscriber Server ("HSS").

10. System according to claim 9,characterised by anW2* interface between the WebRTC client and theWAS for exchanging signalling messages.

11 12

EP 3 007 401 A1

8

EP 3 007 401 A1

9

EP 3 007 401 A1

10

EP 3 007 401 A1

11

EP 3 007 401 A1

12

EP 3 007 401 A1

13

5

10

15

20

25

30

35

40

45

50

55

EP 3 007 401 A1

14

5

10

15

20

25

30

35

40

45

50

55

EP 3 007 401 A1

15

REFERENCES CITED IN THE DESCRIPTION

This list of references cited by the applicant is for the reader’s convenience only. It does not form part of the Europeanpatent document. Even though great care has been taken in compiling the references, errors or omissions cannot beexcluded and the EPO disclaims all liability in this regard.

Non-patent literature cited in the description

• C. JENNINGS ; A. NARAYANAN ; D. BURNETT ;A. BERGKVIST. WebRTC 1.0: Real-time communi-cation between browsers. W3C, W3C Working Draft,01 July 2014, http://dev.w3.org/2011/webrtc/edi-tor/archives/20140704/webrtc.html [0004]

• 3GPP TS 23.228 V12.5.0 Annex U, June 2014 [0007]