====== Call ====== {{ :ixnx:wrtc:description:call_block_diagram.png?nolink&400 |}} wrtc_kit is a software module that allows apps and webpages to easily integrate webRTC audio and video calls. When placing a call the following happens: The app or webpage in client **A** calls wrtc_kit function [[ixnx:wrtc:js:api:wrtc:call|Call()]] with the name of whom to call as argument. Thus if client **A** want to call Dave then it executes wrtc_kit function: wrtc.Call("Dave") Now the wrtc_kit in **A** will collect data about client **A** (what IP address it has, capabilites, etc) and will then send an [[ixnx:wrtc:rtcgate:offer|offer]] RTCgate command through its web socket connection to the Ingate unit's **web socket server**. The web socket server maintains a list of all connected clients. It finds that Dave is logged in on client **B**. Thus it forwards the [[ixnx:wrtc:rtcgate:offer|offer]] through its web socket connection with client **B**. wrtc_kit in client **B** will raise an [[ixnx:wrtc:js:api:wrtc:onincomingcall|onIncomingCall()]] event to the app or webpage running it so the user can be asked if he accepts the call or not. If the call is accepted wrtc_kit function [[ixnx:wrtc:js:api:call:answercall|answerCall()]] is called. Then wrtc_kit in client **B** will collect its IP address, capabilites etc and send back an [[ixnx:wrtc:rtcgate:answer|answer]] RTCgate command through its web socket connection to the Ingate unit. The web socket server in Ingate unit forwards this answer back to client **A**. Now the wrtc_kit in client **A** will establish a real time media connection with client **B**. Most of the time, if clients **A** and **B** can reach each other, a direct connection is established between the two clients. If one of the clients are on the Internet appropriate ports will be opened in the firewall. If one of the clients are behind a remote NAT and thus have no direct way of reach then the Ingate unit's built-in QTURN server will be used to forward the media streams. Summary: * The app or webpage using wrtc_kit can easily start a call using just one function call * wrtc_kit takes care of all the hassle setting up the call * signaling between clients go through web socket channels to Ingate unit that forwards commands to correct recipients * real time media streams go directly between clients if possible, or are forwarded by Ingate unit if necessary ====== SIP Call ====== {{ :ixnx:wrtc:description:sip_call_diagram.png?nolink&400 |}} When placing a SIP call it is very similar for the app or webpage using wrtc_kit but quite a bit different behind the scenes: The app or webpage in client **A** calls wrtc_kit function [[ixnx:wrtc:js:api:wrtc:call|Call()]] with the SIP address of whom to call as argument. Thus if client **A** wants to call "dave@sipdomain.com" then it executes wrtc_kit function: wrtc.Call("dave@sipdomain.com") Now the wrtc_kit in **A** will collect data about client **A** (what IP address it has, capabilites, etc) and will then send an [[ixnx:wrtc:rtcgate:offer|offer]] RTCgate command through its web socket connection to the Ingate unit's **web socket server**. The web socket server recognises it is a SIP address **A** is trying to call (it contains a @). It then creates a SIP user agent **SIP UA** that contacts the SIP registrar for sipdomain.com to ask where dave@sipdomain.com is. The SIP registrar could either be the Ingate unit's built-in one or any external. As dave has registered itself at the SIP registrar it can tell where he is, at which IP address he can be contacted. Now the **SIP UA** translates the RTCgate offer command to a SIP invite and sends it to SIP phone **C**. It then starts ringing. When user picks up phone **C** it will send a SIP answer back to the **SIP UA** that translates it back to an RTCgate answer command and sends it back to the web socket server that forwards it to client **A**. Now the wrtc_kit in client **A** will establish a real time media connection with SIP phone **C**. Most of the time, if client **A** and phone **C** can reach each other, a direct connection is established between them. If one of them are on the Internet appropriate ports will be opened in the firewall. If one of them are behind a remote NAT and thus have no direct way of reach then the Ingate unit's built-in QTURN server will be used to forward the media streams. Some SIP telephones cannot handle encrypted data streams. In such case the encrypted media stream from client **A** will be sent to the Ingate unit's **Voice bridge** that decrypts the media stream before it is sent to the telephone. If a telephony provider has SIP FXO services then the remote telephone called to could also be an ordinary telephone. The **SIP UA** can also register itself as a SIP client on either the Ingate unit's own SIP registrar or any remote one. In such case it is also capable of receiving incoming SIP calls. Summary: * The app or webpage using wrtc_kit can just as easily start a SIP call as a webRTC call * wrtc_kit takes care of all the hassle setting up the call * the Ingate unit acts as a bridge between webRTC clients as the SIP world * real time media streams still go directly between clients if possible, or are forwarded by Ingate unit if necessary