Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
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
Editor's Notes
[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
