Abstract:
A WebRTC system, device and method enabling a P2P communication when both ends of a communication are WebRTC enabled devices. The system and devices also enable a WebRTC client to SIP device communication. A SIP interworking function is configured to receive a SDP1 from an originating WebRTC and obtain local media information from a media interworking function. The first SIP interworking function is configured to create a SDP2 based on the SDP1 and the local media information, create a SIP message comprising a message-body field including the SDP2 and an SIP extension header field including the SDP1, and send the SIP message to an IMS or SIP server.

Description:
TECHNICAL FIELD 
       [0001]    The present invention is generally directed to WebRTC clients communicating with IP Multimedia System (IMS) or Session Initiation Protocol (SIP) networks, and more particularly to enabling WebRTC client&#39;s peer-to-peer (P2P) communications through an IMS or SIP network. 
       BACKGROUND 
       [0002]    WebRTC mandates that terminals in a WebRTC network support the Secure Real-time Transport Protocol (SRTP) and the Interactive Connectivity Establishment (ICE) framework in order to communicate. The mode of SRTP can be the Datagram Transport Layer Security (DTLS) protocol. If one of the participant devices does not support it the communication will fail. 
         [0003]    For existing software IP (SIP) devices, whether SIP Devices in Enterprises or SIP Devices in Service Providers (IP Multimedia Subsystem (IMS) based or non-IMS based): 
         [0004]    Most of them do not support ICE; 
         [0005]    Most of them do not support SRTP. Although some support SRTP, most legacy ones support Session Description Protocol Security Descriptions (SDES), not the DTLS-SRTP; and 
         [0006]    3GPP Standard (3GPP.33.328) chose SDES mode for SRTP. 
         [0007]    If a WebRTC device wants to inter-connect with an IMS or a SIP network, it has to use a WebRTC-SIP Interworking Function, which consists of a Web Server, a SIP Interworking Function, and a Media Interworking Function, Besides the translation between HTTP and SIP signaling, this WebRTC-SIP Interworking Function needs to convert between SRTP and Real-time Transport Protocol (RTP) as well as ICE termination. 
         [0008]    The introduction of WebRTC-SIP Interworking Function introduces another issue: When both ends of a communication are WebRTC enabled devices the media path still relays from the Media Interworking Function while WebRTC was designed for P2P purposes. 
         [0009]    There is desired a solution to allow media to perform P2P communication when both ends are WebRTC enabled devices in an IMS or SIP network. 
       SUMMARY 
       [0010]    The present disclosure achieves technical advantages as a WebRTC system, device and method enabling a P2P communication when both ends of a communication are WebRTC enabled devices. The system and devices also enable a WebRTC client to SIP device communication. A SIP interworking function is configured to receive a SDP1 from an originating WebRTC and obtain local media information from a media interworking function. The first SIP interworking function is configured to create a SDP2 based on the SDP1 and the local media information of the media interworking function, and create a SIP message comprising a message body field including the SDP2 and an SIP extension header field including the SDP1, and send the SIP message to an IMS or SIP server. 
         [0011]    In one embodiment, there is provided a method of establishing a communication between two WebRTC browsers in a WebRTC network. The method includes receiving, by a Session Initiation Protocol (SIP) interworking function from an originating WebRTC browser, an original caller Session Description Protocol (SDP) which supports a Secure Real-time Transport Protocol (SRTP) and an Interactive Connectivity Establishment (ICE); obtaining, by the SIP interworking function, local media information from a media interworking function; and creating, by the SIP interworking function, a converted caller SDP which does not support the SRTP and the ICE based on the original caller SDP and the local media information from the media interworking function, creating an SIP message comprising the converted caller SDP and the original caller SDP, and sending the SIP message to a receiving WebRTC browser via an IP Multimedia System (IMS) or SIP server. 
         [0012]    In another embodiment, there is provided a network apparatus for establishing a communication between two clients in a communication network. The network apparatus includes a memory and a processor coupled to the memory, wherein the memory includes instructions that when executed by the processor causes the network apparatus to: receive, from an originating WebRTC browser, an original caller Session Description Protocol (SDP) including a SDP information of the originating WebRTC browser, obtain local media information from a media interworking function, create a converted caller SDP based on the original caller SDP and the local media information from the media interworking function, create an SIP message comprising the converted caller SDP and the original caller SDP, and send the SIP message to a receiving client via an IP Multimedia System (IMS) or SIP server. 
         [0013]    In yet another embodiment, there is provided a communication system for establishing a communication in a WebRTC network. The communication system includes an originating Session Initiation Protocol (SIP) interworking network apparatus and a terminating SIP interworking network apparatus. The originating SIP interworking network apparatus is configured to: receive an original caller Session Description Protocol (SDP) including a SDP information from an originating WebRTC browser, obtain local media information from a media interworking function, create a converted caller SDP based on the original caller SDP and the local media information from the media interworking function, create an SIP message comprising the converted caller SDP and the original caller SDP, and send the SIP message to the terminating SIP interworking network apparatus. The terminating SIP interworking network apparatus is configured to: receive the SIP message, retrieve the original caller SDP and send the original caller SDP to a receiving WebRTC browser via a Web server. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]    For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, wherein like numbers designate like objects, and in which: 
           [0015]      FIG. 1  illustrates a block diagram of WebRTC clients communicating with an IMS or SIP network configuration establishing a P2P communication between WebRTC clients; 
           [0016]      FIG. 2  illustrates a message flow diagram establishing the P2P communication between WebRTC clients through the IMS or SIP network; 
           [0017]      FIG. 3  illustrates a block diagram of WebRTC clients communicating with an IMS or SIP network configuration establishing a communication between a WebRTC client and a SIP device; 
           [0018]      FIG. 4  illustrates a message flow diagram establishing the communication between a WebRTC client and a SIP device with reference to  FIG. 3 ; 
           [0019]      FIG. 5  illustrates an embodiment of a network unit; and 
           [0020]      FIG. 6  illustrates a typical, general-purpose network component. 
       
    
    
     DETAILED DESCRIPTION 
       [0021]    This disclosure includes at least 2 embodiments. A first embodiment is illustrated with respect to a first network diagram shown in  FIG. 1 , with the message flow diagram shown in  FIG. 2 . A second embodiment is illustrated with respect to a second network diagram shown in  FIG. 3 , with the message flow diagram shown in  FIG. 4 . 
         [0022]    Workflow 1 
         [0023]    Workflow 1 illustrates call processing to establish a P2P call between WebRTC clients  12  and  28 . 
         [0024]    Referring to  FIG. 1  there is shown an IMS or SIP network at  10  seen to include a first WebRTC client  12  having a browser  14  and supported by a web server  16 . A first SIP Interworking Function  18  is configured to communicate with an IMS or Other SIP Server  20 , which in turn is configured to communicate with a second SIP Interworking Function  22 . The second SIP Interworking function  22  is configured to communicate with a second WebRTC client  28  having a respective browser  30  via a web server  32 . A pair of Media Interworking Functions  34  and  36  are configured to exchange media communications between the first WebRTC client browser  14  and the second WebRTC client browser  30 . 
         [0025]    Referring to  FIG. 2  in view of  FIG. 1 , at step  40 , WebRTC client browser  14  initiates a call with web server  16 , creating a Session Description Protocol (SDP) with SRTP and ICE description for example labeled as an original caller Session Description Protocol or SDP1 and sending it to web server  16  by HTTP or a WebSocket connection. 
         [0026]    At step  42 , web server  16  passes SDP1 to SIP Interworking Function  18 . 
         [0027]    At step  44 , the SIP Interworking Function  18  on the originating side of the call sends media information of SDP1 to Media Interworking Function  34 , and obtains local media information of Media Interworking Function  34 . The SIP Interworking Function  18  then creates a converted caller Session Description Protocol (for example labeled as SDP2) with RTP and without ICE description based on the original caller SDP1 and the local media information of Media Interworking Function. The SIP Interworking Function  18  then embeds the newly created SDP2 into the message-body field of a SIP request message (typically INVITE message). In the meantime, the SIP Interworking Function  18  embeds the SDP1 into a SIP extension header field, for example, X-WebRTC-SDP. Then, the SIP Interworking Function  18  sends the SIP request message including SDP2 and the embedded SDP1 to the IMS or Other SIP server  20  at step  46 . 
         [0028]    At step  48 , when the IMS or SIP Server  20  receives the SIP request message it just ignores this X-WebRTC-SDP header because it does not recognize this extension header, and instead uses SDP2 for further processing. The X-WebRTC-SDP header is passed through. 
         [0029]    At step  50 , the SIP Interworking Function  22  on the terminating side receives and processes the SIP request message from the IMS or SIP Server  20 . The SIP Interworking Function  22  detects that the SIP request message contains the X-WebRTC-SDP header and then retrieves the SDP1 from the X-WebRTC-SDP header. 
         [0030]    At step  52 , the SIP Interworking Function  22  sends the SDP1 via web server  32  to the receiving web browser  30  of WebRTC client  28 . Because the SIP Interworking Function  22  knows that the WebRTC clients can make a P2P communication, it will not send any media information to the Media Interworking Function  36  or apply any media resources from the Media Interworking Function  36 . 
         [0031]    At step  54 , the WebRTC client  28  uses SDP1 from the WebRTC client  12  to negotiate media information, and then creates and sends a callee original Session Description Protocol (for example labeled as SDP3) with SRTP and ICE description to web server  32 . 
         [0032]    At step  56 , the web server passes SDP3 to the SIP Interworking Function  22 . 
         [0033]    At step  60 , the SIP Interworking Function  22  on the terminating side creates a SIP response message (typically 1xx/2xx response) and embeds SDP3 into a X-WebRTC-SDP extension header field of this SIP response message. Because the WebRTC clients  12  and  28  can make a P2P communication, to avoid media stream interruption detection in the IMS or SIP Server  20 , the SIP Interworking Function  22  creates a SDP answer with a HOLD state for SDP2, for example, labeled as converted callee Session Description Protocol or SDP4, and embeds SDP4 into the message-body field of the SIP response message (1xx/2xx) and sends it to IMS or SIP Server  20 . 
         [0034]    At step  62 , when IMS or SIP Server  20  receives this SIP response message, it will ignore this X-WebRTC-SDP header of the SIP response message, and instead, it uses SDP4 for further processing. The X-WebRTC-SDP header including SDP3 is, however, passed through to SIP Interworking Function  18 . 
         [0035]    At step  64 , the SIP Interworking Function  18  on the originating side receives the SIP response message, and detects that the SIP response message contains the X-WebRTC-SDP header, and retrieves the SDP3 from the X-WebRTC-SDP header. The SIP Interworking Function  18  sends SDP3 to web server  16 , and at step  66  to the originating browser  14  of WebRTC client  12  via web server  16 . 
         [0036]    At step  70 , the SIP Interworking Function  18  sends commands to the Media Interworking Function  34  to release the resource. 
         [0037]    At step  72 , the originating browser  14  of WebRTC client  12  uses SDP3 to negotiate media with the terminating browser  30  of WebRTC client  28  directly, and establish a P2P communication with browser  30  of terminating WebRTC client  28 . 
         [0038]    Workflow 2 
         [0039]    Workflow 2 illustrates call processing to establish a call between WebRTC client  12  and SIP device  39 , wherein like numeral refer to like elements of  FIG. 1 . 
         [0040]    Referring to  FIG. 3  there is shown a IMS or SIP network at  80  seen to include first WebRTC client  12  having browser  14  and supported by web server  16 . The SIP Interworking Function  18  is configured to communicate with IMS or Other SIP Server  20 , which in turn is configured to communicate with a SIP device  38 . Media Interworking Function  34  is configured to exchange media communications between browser  14  of the first WebRTC client  12  and SIP device  38  via an IMS or SIP domain media server  36 . 
         [0041]    Referring to  FIG. 4  in view of  FIG. 3 , at step  82  the browser  14  of the originating WebRTC client  12  initiates a call, creating an original caller Session Description Protocol (for example labeled as SDP1) with SRTP and ICE description and sending SDP1 to web server  16  by HTTP or a WebSocket connection. 
         [0042]    At step  84 , the web server  16  passes SDP1 to SIP Interworking Function  18 . 
         [0043]    At step  86 , the SIP Interworking Function  18  on the originating side sends media information of SDP1 to Media Interworking Function  34 , and obtains local media information of Media Interworking Function  34 . The SIP Interworking Function  18  then creates a converted caller Session Description Protocol (for example labeled as SDP2) with RTP and without ICE description based on the SDP1 and the local media information of Media Interworking Function. The SIP Interworking Function  18  then embeds the newly created SDP2 into the message-body field of a SIP request message (typically INVITE message). In the meantime, the SIP Interworking Function  18  embeds the original SDP1 into a SIP extension header field, for example X-WebRTC-SDP, and then sends the SIP message including the SIP extension header to IMS or Other SIP server  20  at step  88 . 
         [0044]    At step  90 , when the IMS or SIP Server  20  receives this SIP request message, it will ignore this X-WebRTC-SDP header because it does not recognize this extension header, and instead uses SDP2 for further processing. The X-WebRTC-SDP header including SDP1, however, is passed through to SIP device  38 . 
         [0045]    At step  92 , SIP device  38  will not recognize the X-WebRTC-SDP header and will uses SDP2 to perform media negotiation with IMS or SIP domain media server  36  and at step  93  returns local media description(for example a callee original Session Description Protocol, labeled as SDP3) with RTP without ICE description to IMS or Other SIP Server  20 . 
         [0046]    At step  94 , when IMS or Other SIP Server  20  receives the SIP response message from SIP device  38 , it uses SDP3 for further processing, and sends the SIP response to the SIP Interworking Function  18 . 
         [0047]    At step  96 , when the SIP Interworking Function  18  receives the SIP response message, it cannot find the X-WebRTC-SDP header, and will assume that the SIP device  38  does not support WebRTC, and responsively sends the media information of SDP3 to Media Interworking Function  34 . SIP Interworking Function  18  then creates a converted callee Session Description Protocol (for example labeled as SDP4) with SRTP and ICE description based on SDP3 and the local media information of Media Interworking Function, and at step  98  sends SDP4 to web server  16 . 
         [0048]    At step  100 , the web server  16  sends SDP4 to browser  14  of originating WebRTC client  12 . 
         [0049]    At step  102 , browser  14  of the WebRTC client  12  uses this SDP4 to perform media negotiation with Media Interworking Function  34 , and starts ICE connectivity check. The originating WebRTC client  12  and the SIP device  38  use Media Interworking Function  34  and IMS or SIP Domain Media Server  36  to connect the media. 
         [0050]    Advantageously, by adding the SIP extension header (for example, X-WebRTC-SDP) including the WebRTC client  12  original SDP information, the WebRTC-SIP Interworking Function  18  enables the WebRTC client  12  to use the IMS or SIP Server  20  not only to connect with a SIP device  38 , but also make a P2P communication directly with another WebRTC client  28 . 
         [0051]    An alternative solution comprises using the SIP multipart message bodies mechanism instead of using the SIP extension header, by adding the original SDP information of the WebRTC client  12  into the message-body field of a SIP message (multibody), the WebRTC-SIP Interworking Function  18  enables the WebRTC client  12  to use the IMS or Other SIP Server  20  to not only connect with the SIP device  38 , but also make a P2P communication directly with another WebRTC client  28 . 
         [0052]    In a first example of implementing the X-WebRTC-SDP extension header (It can be used to Workflow 1 and Workflow 2), the WebRTC-SIP Interworking Functions compresses the original SDP string by a compression algorithm and encodes it by base 64 encoding: 
         [0053]    X-WebRTC-SDP: UmFyIRoHAM+QcwAADQAAAAAAAADOUXQgkDoA9gIAA . . . . 
         [0054]    Both of the WebRTC-SIP Interworking Functions  18  and  22  perform the same algorithm to encode and decode the SDP. 
         [0055]    In a second example of implementing the X-WebRTC-SDP extension header (It can be used to Workflow 1 and Workflow 2), the WebRTC-SIP Interworking Function  18  embeds a SDP key in the extension header and saves the key value pair (for example SDP key and original SDP string) into an external database. The WebRTC-SIP Interworking Functions put and retrieve the SDP string from the same external database. 
         [0056]      FIG. 5  illustrates an embodiment of a network unit  1000 , which may be any device that transports and processes data through network  100 . For instance, the network unit  1000  may correspond to or may be located in any of the system nodes described above, such as the device or server described as above, for example, the WebRTC-SIP Interworking Function as described above, the web server, WebRTC client, IMS or SIP domain media server, Media Interworking Function, or SIP device, etc. The network unit  1000  may correspond to or may be located in any of the system nodes described above, such as a MN, AoS, content router R, and AS. The network unit  1000  may also be configured to implement or support the schemes and methods described above. The network unit  1000  may comprise one or more ingress ports or units  1010  coupled to a receiver (Rx)  1012  for receiving signals and frames/data from other network components. The network unit  1000  may comprise a content aware unit  1020  to determine which network components to send content to. The content aware unit  1020  may be implemented using hardware, software, or both. The network unit  1000  may also comprise one or more egress ports or units  1030  coupled to a transmitter (Tx)  1032  for transmitting signals and frames/data to the other network components. The receiver  1012 , content aware unit  1020 , and transmitter  1032  may also be configured to implement at least some of the disclosed schemes and methods above, which may be based on hardware, software, or both. The components of the network unit  1000  may be arranged as shown in  FIG. 5 . 
         [0057]    The content aware unit  1020  may also comprise programmable content forwarding plane block  1028  and one or more storage blocks  1022  that may be coupled to the programmable content forwarding plane block  1028 . The programmable content forwarding plane block  1028  may be configured to implement content forwarding and processing functions, such as at an application layer or L3, where the content may be forwarded based on content name or prefix and possibly other content related information that maps the content to network traffic. Such mapping information may be maintained in one or more content tables (e.g., CS, PIT, and FIB) at the content aware unit  1020  or the network unit  1000 . The programmable content forwarding plane block  1028  may interpret user requests for content and accordingly fetch content, e.g., based on meta-data and/or content name (prefix), from the network or other content routers and may store the content, e.g., temporarily, in the storage blocks  1022 . The programmable content forwarding plane block  1028  may then forward the cached content to the user. The programmable content forwarding plane block  1028  may be implemented using software, hardware, or both and may operate above the IP layer or L2. 
         [0058]    The storage blocks  1022  may comprise a cache  1024  for temporarily storing content, such as content that is requested by a subscriber. Additionally, the storage blocks  1022  may comprise a long-term storage  1026  for storing content relatively longer, such as content submitted by a publisher. For instance, the cache  1024  and the long-term storage  1026  may include Dynamic random-access memories (DRAMs), solid-state drives (SSDs), hard disks, or combinations thereof. 
         [0059]    The network components described above may be implemented on any general-purpose network component, such as a computer or network component with sufficient processing power, memory resources, and network throughput capability to handle the necessary workload placed upon it.  FIG. 6  illustrates a typical, general-purpose network component  1100  suitable for implementing one or more embodiments of the components disclosed herein. The network component  1100  includes a processor  1102  (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage  1104 , read only memory (ROM)  1106 , random access memory (RAM)  1108 , input/output (I/O) devices  1110 , and network connectivity devices  1112 . The processor  1102  may be implemented as one or more CPU chips, or may be part of one or more application specific integrated circuits (ASICs). 
         [0060]    The secondary storage  1104  is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM  1108  is not large enough to hold all working data. Secondary storage  1104  may be used to store programs that are loaded into RAM  1108  when such programs are selected for execution. The ROM  1106  is used to store instructions and perhaps data that are read during program execution. ROM  1106  is a non-volatile memory device that typically has a small memory capacity relative to the larger memory capacity of secondary storage  1104 . The RAM  1108  is used to store volatile data and perhaps to store instructions. Access to both ROM  1106  and RAM  1108  is typically faster than to secondary storage  1104 . 
         [0061]    It maybe advantageous to set forth definitions of certain words and phrases used throughout this patent document. The terms “include” and “comprise,” as well as derivatives thereof, mean inclusion without limitation. The term “or” is inclusive, meaning and/or. The phrases “associated with” and “associated therewith,” as well as derivatives thereof, mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, or the like. 
         [0062]    While this disclosure has described certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure, as defined by the following claims.