Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (18)
Semelhante a IEEE latincom2012
Semelhante a IEEE latincom2012 (20)
Último
Último (20)
IEEE latincom2012
- 1. Bridging the gap between SIP and The WWW for an ubiquitous Real Time Communications network José Luis Millán Villegas mailto:jmillan@aliax.net @jomivi http://www.jssip.net IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 2. Lecturer Involved in VoIP since 2008 Co-author of draft-ietf-sipcore-sip-websocket Main author of JsSIP (The JavaScript SIP Library) Always around Open Standards and Free Software IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 3. The World Wide Web ➔ Born as a way to share information ➔ Nowadays used for..., everything ➔ All is done from the browser ➔ Easy to use ➔ Centralized ➔ Is it ready for Real-time Communications? IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 4. SIP ➔ RFC 3261 (2002) ➔ Application-layer control protocol for session management ➔ Signaling protocol for VoIP ➔ Intelligence is in the User Agent IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 5. SIP (cont.) ➔ Bases its fundamentals on existing Internet specifications ➔ Internet Message Format (RFC 2822) ➔ Uniform Resource Identifiers (RFC 2396) ➔ HTTP Authentication (RFC 2617) ➔ The TLS Protocol (RFC 5246) ➔ Works along with many existing protocols ➔ Session Description Protocol (RFC 4566) ➔ Real Time Protocol (RFC 3550) ➔ Secure Real Time Protocol (RFC 3711) ➔ ZRTP (RFC 6189) ➔ Only involved in the signaling part of the session IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 6. SIP (cont.) ➔ Simple and extensible core ➔ User location ➔ Mobility ➔ Session setup/management ➔ Used in concert with other SIP extensions to build a complete multimedia architecture ➔ Call Control ➔ Security ➔ Conferencing ➔ Instant Messaging ➔ Presence ➔ ... IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 7. SIP Born Into IP Newtorks ➔ Ready for packet loss ➔ Defines its own retransmission mechanisms ➔ Provides reliability under unreliable transports (UDP) ➔ Works with both IPv4 and IPv6 ➔ Independent of underlying transport protocol IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 8. SIP User Location User location database biloxi.com sip:bob@biloxi.com proxy/registrar REGISTER 401 Unauthorized REGISTER + Credentials 200 OK IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 9. SIP Session Establishment atlanta.com biloxi.com sip:alice@atlanta.com sip:bob@biloxi.com INVITE 100 Trying INVITE 100 Trying INVITE 180 Ringing 180 Ringing 180 Ringing 200 OK 200 OK 200 OK ACK RTP BYE 200 OK IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 10. Transports in SIP ➔ Mandates UDP + TCP ➔ TCP to handle larger messages ➔ Defines the use of TLS ➔ Hop by hop security ➔ SCTP as a Transport for SIP (RFC 4168) ➔ Server to server communications ➔ Message based instead of stream based ➔ Better performance in loss conditions ➔ Easier parsing ➔ Multihoming IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 11. Transports in SIP (recap) ➔ UDP, TCP, TLS, SCTP, TLS-SCTP ➔ Non of them can be used in a web browser to establish a connection with a server ➔ Here is the gap between SIP and The WWW IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 12. HTTP ➔ HTTP/1.1 (RFC 2616) 1999 ➔ Text-based application layer protocol ➔ Synchronous request/response ➔ Browser requests, server responds ➔ No way to receive asynchronous notifications from the server ➔ Not designed for Full-Duplex Real-Time IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 13. HTTP based Web Real-Time ➔ Real-time attempts ➔ Polling ➔ The browser sends HTTP requests at regular intervals and immediately receives a response ➔ Long-polling ➔ The browser sends a request to the server and the server keeps the request open for a given period of time. If a notification is received within that period, a response containing the message is sent to the client IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 14. HTTP based Web Real-Time (cont.) ➔ [Long] polling based chat application HTTP Server Any message for me? Any message for me? Any message for me? Hey! Any message for me? Bob says: 'Hey!' IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 15. HTTP based Web Real-Time (cont.) ➔ Flash (Adobe) ➔ Propietary ➔ Plugin required ➔ Not supported in mobile platforms IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 16. HTTP based Web Real-Time (recap) ➔ Overhead ➔ Bandwidth waste ➔ Battery problem in mobile devices IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 17. WebSocket ➔ RFC 6455 (December 2011) ➔ Bidirectional, full-duplex communication between web client and server ➔ Connection oriented transport (layered over TCP) ➔ Tunneled over TLS for secure communications ➔ HTTP is used in handshake ➔ Easily integration with firewall rules ➔ Reuses existing infrastructure IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 18. WebSocket Opening Handshake IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 19. WebSocket API ➔ API Standarization by W3C ➔ http://dev.w3.org/html5/websockets ➔ Controlled by the JavaScript application from the browser ➔ Methods ➔ send( text / binary ) ➔ close( ) ➔ Callbacks ➔ onopen ➔ onerror ➔ onclose ➔ onmessage IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 20. WebSocket Example ➔ The web browser connects to the WebSocket server ➔ The user is alerted when a notification arrives from the server IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 21. WebSocket Implementation in Web Browsers Source: http://caniuse.com/websockets IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 22. WebSocket as a Transport for SIP draft-ietf-sipcore-sip-websocket-5 The WebSocket Protocol as a Transport for SIP This specification defines a new WebSocket sub-protocol (as defined in section 1.9 in RFC6455) for transporting SIP messages between a WebSocket client and server [...] IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 23. WebSocket as a Transport for SIP Example I ➔ SIP Registration over WebSocket IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 24. WebSocket as a Transport for SIP Example I (cont.) ➔ WebSocket Opening Handshake IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 25. WebSocket as a Transport for SIP Example I (cont.) ➔ REGISTER request ➔ Sent over the just created permanent WebSocket connection IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 26. WebSocket as a Transport for SIP Example I (cont.) ➔ Response to REGISTER IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 27. WebSocket as a Transport for SIP Example II example.com SIP proxy/registrar INVITE sip:alice@example.com INVITE sip:alice@example.com WS TCP Web browser SIP phone sip:alice@example.com sip:bob@example.com IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 28. WebSocket as a Transport for SIP (cont.) ➔ Devices which can't establish other transport connections but WebSocket connections are welcome to the SIP world ➔ SIP networks are expanded thanks to this new devices ➔ Web browsers can now speak SIP IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 29. WebSocket as a Transport for SIP (recap) ➔ We can use SIP from the web browser ➔ But we want to talk and see each other ➔ How to get the media... ➔ Flash? ➔ Java Applet? ➔ ActiveX? ➔ MS Silverlight? ➔ ..., in an open standard way IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 30. WebRTC Real Time Communications in Web Browsers The goal is through simple Javascript Application Program Interface (API) to make browsers Real-Time Communication (RTC) capable SRTP/DATA IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 31. State of the Art of RTC in Web Browsers ➔ Facebook & Skype ➔ Google Hangouts ➔ Cisco Webex ➔ Installation required ➔ Proprietary plugins required IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 32. WebRTC Use Cases ➔ Remote classroom ➔ Customer service ➔ Remote assistance ➔ Online health care ➔ Social networks ➔ What else? IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 33. WebRTC Architecture Source: http://www.webrtc.org IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 34. WebRTC Media ➔ Mandatory to implement codecs ➔ Narrowband audio: G.711 ➔ Wideband audio: Opus ➔ Video: Debate between VP8 y H.264 AVC IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 35. WebRTC Media Transport ➔ Secure by design ➔ SRTP (RFC 3711): Secure RTP ➔ Uses symmetric key cryptography to offer confidentiality and integrity ➔ DTLS (RFC 6347): Datagram Transport Layer Security ➔ Equivalent to TLS, but over UDP ➔ Used for SRTP key exchange IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 36. WebRTC Multimedia Session OFFER / ANSWER HTML/CSS/JavaScript HTML/CSS/JavaScript SRTP/DATA IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 37. WebRTC Multimedia Session Elements ➔ ICE (RFC 5245): Interactive Connectivity Establishment ➔ Candidate handling (Offer/Answer generation) ➔ Local candidates (endpoint network interfaces) ➔ Server reflexive candidates. Uses STUN ➔ Relay candidates. Uses TURN ➔ Connectivity checks using STUN IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 38. WebRTC Multimedia Session Elements (cont.) ➔ STUN (RFC 5389): Session Traversal Utilities for NAT ➔ Permits an endpoint to determine the IP address and port allocated to it by a NAT ➔ Connectivity checks between two endpoints ➔ Keep-alive protocol to maintain NAT bindings IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 39. WebRTC Multimedia Session Elements (cont.) ➔ TURN (RFC 5766): Traversal Using Relays around NAT ➔ Used when peer to peer communication is not possible ➔ When both peers are behind symetric NATs ➔ Guarantees the communication ➔ Drawbacks ➔ Inserts delay ➔ Server resources needed IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 40. WebRTC Offer/Answer model ➔ SDP (RFC 3264): Session Description Protocol ➔ Already used in SIP ➔ Session description ➔ Listening IP address & ports ➔ Offering media attributes (codecs, rates, etc) IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 41. WebRTC Offer/Answer model (cont.) Listening IP addresses and ports AUDIO CODECS Listening IP addresses and ports VIDEO CODECS IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 42. WebRTC Multimedia Session (cont.) ➔ IP addresses are known ➔ Media capabilities are known ➔ Peer to peer media flow management is solved ➔ We have got a Session Description ➔ Which must be sent to the other peer ➔ …, but WebRTC does not define how ➔ It is up to the web application IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 43. WebRTC Multimedia Session (cont.) ➔ We are in a browser ➔ HTTP [long] polling ➔ Flash ➔ WebSocket IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 44. WebRTC Standards ➔ IETF RTCWeb WG ➔ Defines WEB-browsers based Real-Time Communication Protocols ➔ http://datatracker.ietf.org/wg/rtcweb ➔ W3C WebRTC WG ➔ Defines a set of ECMAScript APIs to manage the WebRTC stack and multimedia sessions ➔ http://www.w3.org/TR/webrtc IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 45. WebRTC Standards IETF RTCWeb WG Documents ➔ draft-ietf-rtcweb-audio ➔ WebRTC Audio Codec and Processing Requirements ➔ draft-ietf-rtcweb-data-channel ➔ RTCWeb Datagram Connection ➔ draft-ietf-rtcweb-jsep ➔ Javascript Session Establishment Protocol ➔ draft-ietf-rtcweb-overview ➔ Overview: Real Time Protocols for Brower-based Applications ➔ draft-ietf-rtcweb-qos ➔ DSCP and other packet markings for RTCWeb QoS ➔ draft-ietf-rtcweb-rtp-usage ➔ Web Real-Time Communication (WebRTC): Media Transport and Use of RTP ➔ draft-ietf-rtcweb-security ➔ Security Considerations for RTC-Web ➔ draft-ietf-rtcweb-security-arch ➔ RTCWEB Security Architecture ➔ draft-ietf-rtcweb-use-cases-and-requirements ➔ Web Real-Time Communication Use-cases and Requirements IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 46. WebRTC Implementations ➔ Google Chrome ➔ Lead implementation ➔ Mozilla Firefox ➔ Available in Aurora builds ➔ Opera ➔ Implementation not announced yet ➔ Safari ➔ No comment ➔ IE ➔ Not yet available IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 47. SIP Signaling for WebRTC ➔ Why ➔ Open standard ➔ Mature ➔ Widely deployed ➔ Reuse existing infrastructure IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 48. SIP Signaling for WebRTC (cont.) ➔ How ➔ draft-ietf-sipcore-sip-websocket ➔ Implementations IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 49. JsSIP ➔ Client side pure JavaScript SIP library ➔ http://www.jssip.net ➔ https://github.com/versatica/JsSIP IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 50. JsSIP (cont.) ➔ Lightweight (~140KB) ➔ Provides an API to build SIP clients ➔ Functionalities ➔ Audio/video calls ➔ Instant Messaging ➔ Subscriptions ➔ More to come! IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 51. JsSIP (cont.) ➔ Manages the WebRTC stack in the browser through the WebRTC API ➔ Multimedia device access ➔ Audio/video management ➔ Gets the SDP generated by the WebRTC stack and sends it to the remote party using SIP IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 52. JsSIP API User Agent Creation IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 53. JsSIP API User Agent Callback Definition IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 54. JsSIP API Outbound Calls IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 55. JsSIP API Instant Messaging IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 56. Other Implementations ➔ SIPML5 ➔ http://sipml5.org IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 57. SIP over WebSocket in the Server Side ➔ Why is it necessary SIP WebSocket clients connect to the server and send/receive SIP messages through the WebSocket connection ➔ Does it imply a new SIP node? No. It implies that Proxies and other SIP servers implement WebSocket as a transport protocol, analogous to UDP, TCP, SCTP, etc IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 58. OverSIP ➔ SIP Proxy with WebSocket transport ➔ http://oversip.net ➔ https://github.com/versatica/OverSIP IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 59. Other Implementations ➔ Kamailio ➔ http://www.kamailio.org ➔ Asterisk ➔ http://www.asterisk.org IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 60. Demo Architecture SIP proxy/registrar SIP proxy/registrar jssip.net aliax.net UDP TCP UDP OverSIP SIP Oubound oversip.net WS WS SRTP JsSIP JsSIP sip:jmillan@jssip.net sip:ibc@aliax.net IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 61. SIP Signaling for WebRTC (recap) ➔ WebRTC ➔ draft-ietf-sipcore-sip-websocket ➔ Implementations The gap between SIP en the WWW is bridged! IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
- 62. José Luis Millán Villegas mailto:jmillan@aliax.net @jomivi http://www.jssip.net IEEE LATINCOM 2012 Bridging the gap between SIP and The WWW
Notas do Editor
- [Come back when self presenting.] Talk to you about New things happening in the WWW in the last times How they will affect to the Internet and probably society How they will probably change the way the web is used in the coming years
- - Mi name - Studied in the engineering school of the Basque country in Bilbao, Spain - Work for a Internet Service Provider in Spain, providing VoIP services - I love doing VoIP research and development in my free time
- Was born as a way to share information between researchers in 1989 thanks to Tim Berners-Lee . Nowadays it is used for... (near everything) - read the newspaper - latest news - Keep in touch with people - Purchase and sell anything - It is used to do those and more things “remotely”. security mechanisms, sensible transactions remotely in a secure way. This all is done from a unique program: The Web Browser. - Perhaps the most used and easy to use program The World Wide Web is far away from being a stateless delivery mechanism anymore. It's becoming more and more real-time. It's already widely used for instant messaging, notifications, etc. – -- But.., is it ready for Realtime? We will give an answer to this question later
- SIP is the most widely used signaling protocol for VoIP Specified by the IETF Designed to establish and maintain sessions between two or more entities - Is a text based protocol, the way HTTP is - Uses the request/response transaction model - Client requests and server responds - A SIP entity is both client and server. Client when requesting and server when receiving the request - The intelligence is in the endpoints, by means that two SIP endpoints can completely communicate within each other without the need of an intermediary
- As an IETF specification , SIP is based on many other existing Internet protocols and specifications, which are used to define characteristics like: - SIP message format - SIP resource format - Authentication methods - Transport layer security methods... It works in conjunction with many other existing protocols in order to provide the many different services that SIP can carries on, although it is only involved in the signaling part of the session.
- SIP has a simple and extensible core which defines basically: - how to locate a SIP resource - how to establish an abstract session with one or many SIP resources - how to do this in a secure way Other SIP specifications extend the SIP core in a modular way, defining mechanisms to achieve concret functionalities using SIP.
- We see how a user uploads his current location - Specifies a limited duration he will be located in that location. - He can refresh his location (before time expiration) by sending another REGISTER request with same Call-ID header value - He can de-locate (unregister) himself by specifying the server that the uploading location expiration time is 0 (seconds) - he can ask the location server for his actual registrations A single user can upload many locations - desk hardphone, laptop softphone, mobile device softphone. - each registration can have different priorities in order to define the call reception device priority.
- 1- Alice makes a NAPTR DNS lookup and acquires the IP address and port of the domain proxy (atlanta.com) 2- She wants to establish a session with bob, from biloxi.com. Sends an INVITE SIP request her proxy. The INVITE message carries an SDP with the description of the media session (listening IP, ports, codecs, etc) 3- The proxy will probably authenticate alice by responding the INVITE request with a negative code, and will attach a HTTP challenge on it. Alice will create a digest authentication and re-send the INVITE, this time with an Authentication header containing the digest 4- atlanta proxy sends the INVITE to bobx sip proxy, who will deliver the invitation to bob. Responses from bob will follow the inverse path of the initial request. 5- Finally bob answer the call (200 OK), indicating the media conditions in the body of the response (which is an sdp). Alice indicated her contact direct location in the Invite request and so does bob in the 200 response, meaning this that folloing SIP communication can be done directly between both peers. 6- Both peers start sending media to the negotiated IP address and ports 7- When one of them decides that the session has to be finished, sends a SIP BYE request indicating his willing for session termination. The other peer acknowledges the termination with a 200 SIP response to the BYE request.
- SIP carries network information inside the Messages although it is a is an application layer protocol. Its paiload is not inspected by netowrk routing nodes but by SIP routing ones. A SIP proxy can perfectly receive a SIP INVITE message though UDP, which indicates that the target of the INVITE is to be reached by TCP. There have to be taken several considerations when adopting a transport as a SIP transport due to its nature (reliable or not, size limit, etc) SCTP → Stream Control Transport Protocol. --- Alice sends a INVITE to her proxy using UDP (she wants to talk to bob) Alice's proxy sends the INVITE to bobs Proxy. Biloxy location server finds that bob location is an IP and TCP port, so sends the INVITE via TCP. When responding the (200 OK) to the call, bob indicates his location and specifies that he is listening in a TCP port. This response reaches Alice. This time, the Alice proxy wanted to remain in the path for subsequent request in the session, so it indicated it adding a Record-Route header field to the initial INVITE sent by Alice. Alice then, wants to terminate the session with bob. She sends a BYE message to her proxy using UDP, this message is forwarded to biloxi SIP proxy who inspects the SIP message and sees the message target (Bobs location) with is an SIP and TCP port. Opens then a new TCP connection with bob and relies the BYE message.
- +++ Let's see what is reason of the gap.
- Gmail, Facebook use this kind of technics The way it is done today
- no way to get a full-duplex communication between browser and server +++ WebSocket to the reque!
- The WebSocket Protocol - IETF HYBI WG (BiDirectional or Server-Initiated HTTP) - Very recent specification - HTML 5 compliant browsers - managed via JavaScript interface - For a new WebSocket connection, the browsers establishes a HTTP connection with the server and negotiates an “upgrade” to a persistent WebSocket connection. This negotiation or “handshake”, provides a full duplex permanent connection between the browser and the server. - The WebSocket connection is directly layered over TCP and generates a minimal overhead - It can transport UTF-8 encoded text and binary payload data.
- The WebSocket handshake starts with a HTTP Upgrade request from the client. The Upgrade header field contains the value “websocket” The server responds with a HTTP (101 Switching Protocols) response if the handshake completed successfully does not define format of the data transported is defined in the handshake. Sec-Web Socket-Protocol ” header field.
- This is a example application of websocket. It simply connects to a websocket server (echo.websocket.org). Everything that is sent from the browser, this server sends back again making an 'echo' effect. Source → echo.js Websocket instance (websocket) websocket.addEventListener('message',function(evt){console.log('Message received: '+evt.data)})
- Can we use WebSocket for sending SIP? Specifies the 'sip' websocket subprotocol for transporting SIP messages between a WebSocket connection. -Defines new DNS NAPTR service values (SIP+D2W “ws” / SIPS+D2W “wss”) and procedures for SIP entities implementing the WebSocket transport. Makes possible the use of SIP in environments where non other transport connection can be established. Ie: A web browser. But it's not limited to web browsers in any way. Its in its 5th revision since October 21th Specification : Defines new values for the SIP VIA header ('WS'/'WSS') Defines a new uri transport parameter value ('ws') Relaxes the use of 'received' via parameter because it is not useful (as a WebSocket SIP client is not usually a WebSocket SIP server. Responses must be always sent to the existing connection.) and could reveal sensitive information about the internal topology of the Server's network to the client.
- latincom2012.jssip.net Register Messages Call to an invalid number.. Conclusion: Is just SIP in the browser
- Flash: Plugin required Java Applet: Java required Active X : Ie.., which else uses it? Microsoft Sliverligth ---- Say hello to WebRTC
- WebRTC provides the browser with a RTC engine and a JavaScript API in order to allow any web developer the use of such Real Time Communications engine from its web page. Data is sent 'Directly' between browsers. Peer2peer WebRTC abstracts the complexity of the underlaying RTC protocols into a simple JavaScript API. The API, is defined by the W3C (WWW Consistorium) i n collaboration with the IETF , who defines the underlaying used protocols.
- 2012 Google acquires GIPs (Global IP solutions) in paying 68M$.. and open sources it as WebRTC VideoEngine AudioEngine Codecs Echo canceller, etc Takes care of packet loss, jitter, delay... GIPS did the Skype VoiceEngine
- Interoperation between different browser manufacturers is needed. That's why there must be a consent with minimal mandatory codecs. IETF-85 Atlanta IPR (Intelectual Property Rights)
- Those existing specifications are not new or defined by WebRTC. they are already defined, but very poorly implemented by VoIP manufacturers. although there are encouraged. WebRTC mandates security from the ground , and that is a good starting point. As we will see later, actual implementations will need to update security aspects in order to inter operate with WebRTC.
- Polling: The other party makes HTTP polling to the web server asking for new invitations WebSocket is the only bidirectional full-duplex communication mechanism in the web browser.
- Together they provide a way to set a communication using audio, video and data from any web to other web browsers or any device implementing the technologies used in WebRTC. (Those specified in “Media Session Elements” chapter)
- There is a lot of activity in the IETF RTCWeb Working group. Those are the WG documents but there are many others which are not WG documents already. There are covered
- SIP in web browsers is possible thanks to SIP over WebSocket specification
- How to use SIP as a signaling protocol fro WebRTC - We have got a RTC stack in the browser: WebRTC - We have got a draft which specifies the use of SIP in the browser - How to use SIP as signaling protocol for WebRTC? Let me fix that for you ;)
- - SIP stack for the web browser - JavaScript - free software - main author - downloaded with the web page - WS connection with a SIP server ------ By the time we wrote the draft for using SIP over WebSocket, there wasn't (obviously) any implementation out there, so.., we had to make one. This is the story of JsSIP.
- Once again, by the time we wrote the SIP over WebSocket draft, there wasn't any SIP server supporting WebSocket, so, we had to make one.
- OverSIP fully supports SIP over WebSocket. The perfect SIP Outbound Proxy to be used between JsSIP and any other SIP server. As SIP Outbound Proxy, OverSIP manages WebSocket connections with SIP WebSocket Clients and gives them access to their respective SIP domains through UDP, TCP or TLS-TCP transports.
- Adoption of any existing SIP service from the Web. We've got an RTP stack We've got an specification to use sip in web environments We've got implementations already