A presentation by Tsahi Levent-Levi, Peter Dunkley (Technical Director, Crocodile RCS Ltd), Kevin Wiseman (Chief Architect, CafeX), Rod Apeldoorn (EasyRTC Server Lead, Priologic). Presentation date 19-Nov-2013.

1. 1
11/19/2013

2. Signaling Workshop
Tsahi Levent-Levi
tsahil@bloggeek.me
@tsahil
2
11/19/2013

3. Speakers
• Peter Dunkley
– Technical Director
– Crocodile RCS Ltd
• Kevin Wiseman
– Chief Architect
– CafeX
• Rod Apeldoorn
– EasyRTC Server Lead
– Priologic
3
11/19/2013

4. Peter Dunkley
Technical Director
Crocodile RCS Ltd
SIP OVER WEBSOCKETS
4
11/19/2013

5. What is SIP over WebSockets
• It is exactly the same SIP as SIP over TCP, SIP over
TLS, and SIP over UDP – just over WebSockets
instead
• It can be secure by using Secure WebSockets
• It is about to become an RFC – currently in the IETF
editors queue
• It is widely supported by many open-source projects
5
11/19/2013

6. A quick comparison
Standards Based
SIP over WebSockets XMPP (BOSH/WebSockets)
Open-source support
High
Medium
Vendor tie-in prevention
High
Medium
Ease of use
High
Medium
Client performance
Medium
Medium
Network performance
High
Medium
Ease of interoperability
High
Medium
Standalone applications
High
High
Use existing media servers High
Low
Proprietary
Low
Low
High*
High*
Medium*
Low*
High*
Low
* Dependent on the proprietary option chosen – could be made better or worse depending on
what you chose!
6
11/19/2013

7. Open source support and vendor tiein prevention
• SIP over WebSockets
– At least four well tested open-source Javascript client stacks
– At least six well tested open-source server stacks
• XMPP (BOSH/WebSockets)
– At least two well tested open-source Javascript client stacks
– At least three open-source server stacks
• Proprietary
– Many options (even open-source options) but all different
and incompatible - many are vendor specific
7
11/19/2013

8. Ease of use
• SIP over WebSockets
– It is not hard – you are not implementing the signalling yourself
– Many client library choices with different APIs and complexities
– Many SDK vendors working to make it even easier for you
• XMPP (BOSH/WebSockets)
– It is not hard – you are not implementing the signalling yourself
– Limited client library choices mean that it is harder than it should be
• Proprietary
– Might well be very easy (but might not be) – it depends on your
technology choices
– No easier than SIP if you choose the right SIP client library
8
11/19/2013

9. Client and network performance
• SIP over WebSockets
– Javascript client libraries can be large, but minification and app-cache use mitigate
this almost completely
– The network can have very high performance while making use of years of
developments in real-time signalling and scaling
• XMPP (BOSH/WebSockets)
– Javascript client libraries can be large, but minification and app-cache use mitigate
this almost completely
– The network will be high performance as long as you do not require
interoperability
• Proprietary
– The client library may be small (depending on your vendor choice)
– The network may be high performance (depending on your vendor choice) as you
do not require interoperability
9
11/19/2013

10. Interoperable and standalone
• The triangle vs the trapezoid
• All options are equally suitable for use with the
“triangle”
• SIP over WebSockets is better for use with the
“trapezoid”
• Avoid gateways whenever you can (they add network
cost and complexity)
• Using SIP makes your application compatible with most
existing media servers (commercial and open-source)
11/19/2013
10

11. The Triangle
Server
UA
Media
UA
11
11/19/2013

12. The Trapezoid
Server
UA
Signalling
Media
Server
UA
12
11/19/2013

13. Use cases for SIP over WebSockets
• SIP is well suited for anything requiring interoperability
– Conferencing – do you really want to exclude the guy travelling
who can’t get (or afford) a mobile data connection?
– Online education – why shouldn’t I be able to listen to lectures
through other routes?
– Telemedicine – a huge boon for people living in remote areas
(aren’t those the ones who struggle to get online?)
– Call centres – can I afford to exclude customers who can’t use
(or don’t want to use) WebRTC?
Many of the applications that need to interoperate are high-value
11/19/2013
13

14. Kamailio: WebSocket Handshake
...
tcp_accept_no_cl=yes
...
event_route[xhttp:request] {
set_reply_close();
set_reply_no_connect();
if ($hdr(Upgrade)=~"websocket"
&& $hdr(Connection)=~"Upgrade"
&& $rm=~"GET") {
# Validate as required (Host:, Origin:,
Cookie:)
if (ws_handle_handshake())
exit;
}
xhttp_reply("404", "Not Found", "", "");
}
14
11/19/2013

15. Kamailio: Request Handling
modparam(“nathelper|registrar”, “received_avp”, “$avp(RECEIVED)”)
...
request_route {
route(REQINIT);
route(WSDETECT);
...
route[WSDETECT] {
if (proto == WS || proto == WSS) {
force_rport();
if (is_method(“REGISTER”)) {
fix_nated_register();
} else if
(is_method(“INVITE|NOTIFY|SUBSCRIBE”)) {
add_contact_alias();
}
}
}
...
route[WITHINDLG] {
if (has_totag()) {
if (loose_route()) {
if (!isdsturiset()) {
handle_ruri_alias();
}
...
11/19/2013
15

16. Kamailio: Response Handling
onreply_route {
if ((proto == WS || proto == WSS)
&& status =~ “[12][0-9][0-9]”) {
add_contact_alias();
}
}
16
11/19/2013

17. Kamailio: RTP Profile Conversion (1)
modparam(“rtpproxy-ng”, “rtpproxy_sock”, “udp:localhost:22223”)
...
route[LOCATION] {
...
t_on_failure(“UA_FAILURE”);
}
...
failure_route[UA_FAILURE] {
if (t_check_status(“488”) && sdp_content()) {
if (sdp_get_line_startswith(“$avp(mline)”, “m=”)) {
if ($avp(mline) =~ “SAVPF”)) {
$avp(rtpproxy_offer_flags) = “froc-sp”;
$avp(rtpproxy_answer_flags) = “froc+SP”;
} else {
$avp(rtpproxy_offer_flags) = “froc+SP”;
$avp(rtpproxy_answer_flags) = “froc-sp”;
}
# In a production system you probably need to catch
# “RTP/SAVP” and “RTP/AVPF” and handle them correctly
# too
}
append_branch();
rtpproxy_offer($avp(rtpproxy_offer_flags));
t_on_reply(“RTPPROXY_REPLY”);
route(RELAY);
}
}
...
17
11/19/2013

18. Kamailio: RTP Profile Conversion (2)
modparam(“rtpproxy-ng”, “rtpproxy_sock”, “udp:localhost:22223”)
...
failure_route[UA_FAILURE] {
...
t_on_reply(“RTPPROXY_REPLY”);
route(RELAY);
}
onreply_route[RTPPROXY_REPLY] {
if (status =~ “18[03]”) {
# mediaproxy-ng currently only supports SRTP/SDES – early media
# won't work so strip it out now to avoid problems
change_reply_status(180, “Ringing”);
remove_body();
} else if (status =~ “2[0-9][0-9]” && sdp_content()) {
rtpproxy_answer($avp(rtpproxy_answer_flags));
}
}
...
18
11/19/2013

19. Authentication (1)
• You do not need accounts on the SIP network
• You can federate with existing identity providers
(Facebook, Google+, LinkedIn, Twitter, your own)
• There is a Kamailio module designed for this (and
implementing it elsewhere is easy)
19
11/19/2013

20. Authentication (2)
Web
Service
Calling
UA
OAuth2
Shared secret –
communication
link not
required
SIP
Proxy
You don’t have to
create or manage
accounts on the
SIP
Proxy/registrar
Called
UA
20
11/19/2013

21. Kamailio: Authentication (1)
...
tcp_accept_no_cl=yes
...
modparam(“auth_ephemeral”, “secret”, “kamailio_rules”)
...
modparam(“htable”, “htable”, “wsconn=>size=8;”)
...
event_route[xhttp:request] {
...
# URI format is /?username=foo&password=bar
$var(uri_params) = $(hu{url.querystring});
$var(username) = $(var(uri_params){param.name,username,&});
$var(password) = $(var(uri_params){param.name,password,&});
# Note: username and password could also have been in a Cookie: header
if (!autheph_authenticate(“$var(username)”, “$var(password)”)) {
xhttp_reply(“403”, “Forbidden”, “”, “”);
exit;
}
if (ws_handle_handshake()) {
$sht(wsconn=>$si:$sp::username) = $var(username)
exit;
}
...
event_route[websocket:closed] {
$var(regex) = $si + “:” $sp + “.*”;
sht_rm_name_re(“wsconn=>$var(regex)”);
}
11/19/2013
21

22. Kamailio: Authentication (2)
...
request_route {
route(REQINIT);
route(WSDETECT);
...
if (!(proto == WS || proto == WSS))
route(AUTH);
...
route[WSDETECT] {
if (proto == WS || proto == WSS) {
$var(username) = (str) $sht(wsconn=>$si:$sp::username);
if ($var(username) == $null || $var(username) == “”) {
send_reply(“403”, “Forbidden”);
ws_close(1008, “Policy Violation”);
exit;
}
if (!autheph_check_timestamp(“$var(username)”)
|| (is_method(“REGISTER|PUBLISH”)
&& !autheph_check_to(“$var(username)”))
|| (!has_totag() && !autheph_check_from(“$var(username)”))) {
send_reply(“403”, “Forbidden”);
ws_close(1008, “Policy Violation”);
exit;
}
force_rport();
...
11/19/2013
22

23. Questions?
Code:
https://github.com/crocodilertc
Email:
peter.dunkley@crocodilertc.net
Twitter:
@pdunkley
23
11/19/2013

24. Kevin Wiseman
Chief Architect
CaféX
WHAT IS SIGNALLING
24
11/19/2013

25. The Basics…
• WebRTC Spec does not define the signalling
– It leaves that open to the implementer
• It does define the media descriptor exchange
– Utilises the Session Description Protocol
25
11/19/2013

26. What is signalling
• Communications session control from one party to
another party
• Typically via some location service
– E.g. SIP Registrar, social network, games service
• Describes the requests and responses
– Make call, end call, hold, resume, transfer etc
– Ringing, answer, rejected, established etc
• Mechanism for exchanging media description
– SDP offer/answer exchange
11/19/2013
26

27. Session Description Protocol
• Used to negotiate media between parties
– Media (audio, video), Ports, Codecs, ICE etc
– offer/answer exchange
• The good news:
– Browser generates and consumes SDP offers & answers
• The bad news:
– WebRTC SDP places specific requirements on SDP that
most existing telecom entities do not support
27
11/19/2013

28. Signalling isn't the hard piece with WebRTC
Media and media description are
28
11/19/2013

29. Closed Systems
• Real time coms within Games, Social Networks etc
• No compelling reason to adopt any one approach
over another
– Already know who is who and how to communicate
– No integration into existing telcoms system
– Extend existing control channel for SDP offer/answer, or
– Utilise 3rd party services to provide real time coms
29
11/19/2013

30. WebRTC Gateway
•
•
Proprietary signalling over HTTP or WebSocket between
browser and gateway
Gateway makes sense if:
– The call scenarios you need to support are standard well
defined UC features
• Voice & video: Make call, answer call, end call, transfer call, N-way
call
• IM&P: Send message, receive message, set presence
• Application Event Distribution
– You want to embed UC features as part of a service
– Your SIP infrastructure has limited support for ICE/STUN and
Multiplexing RTP etc
•
Client
SDK
Browser
JSON call control
over WebSocket
SRTP
Fusion
Web
Gateway
Fusion
Media
Broker
De-ICEd,
de-STUNned &
de-multiplexed
RTP
SIP
This is the use case we are seeing almost exclusively
– Customers wanting to embed UC features as part of an overall
service
•
CaféX Implementation
SIP Network
Challenges
– Dependency on gateway exposing features
30
11/19/2013

31. SIP over Websockets
• SIP over web sockets makes sense if:
– The call scenarios you need to support to the browser
require all the features of SIP
– You have developers that can make full use of SIP features on
the browser
– Your SIP end points already support ICE/STUN and
Multiplexing RTP etc
• Challenges
– SIP stack/UA in the browser (dependency on large and
complex JS in Browser)
– SIP interworking with yet another 3rd party SIP stack
– Security – opening up all the features (and potential security
holes) of SIP to the public internet is dangerous
– No benefit to most existing SIP systems – still have to add
web sockets support, still have to add SDP and Media
translation
If Café X had used
SIP over WebSockets
JS SIP
Stack
JS SIP
UA
SIP over
Websocket
Browser
RTP
Fusion
Web
Gateway
Fusion
Media
Broker
De-ICEd,
de-STUNned &
de-multiplexed
RTP
SIP
SIP Network
31
11/19/2013

32. Web Dev & Signalling
• Most Web Devs don’t know or even need to know the
signalling protocol
– Busy enough already
• Web Devs expect a rich functional high level API
– Efficiency & ease of use
• Don’t want to reinvent the wheel every time they want
to add RTC to a web app
– If no API provided the first thing a web dev will do is write one
and re-use next time they need to use the service
32
11/19/2013

33. API Example – Initialisation
<script src="https://<gateway_address>:<8080>/gateway/fusion-client-sdk.js"></script>
//Get hold of the sessionID however your app needs to
var sessionID = getMySessionID();
//Google provide a stun server which you can use or you can use your own.
//Providing any empty array will result in no stun messages being sent.
var stunServers=["stun.l.google.com:19302"];
//Set up initialization success callback before calling start
UC.onInitialised = function() {
//perform tasks associated with successful initialization such as registering listeners on UC objects
};
//Set up initialization failure callback before calling start
UC.onInitialisedFailed = function() {
//perform tasks associated with initialization failure};
//Start my UC session using the Session ID and stun server list
UC.start(sessionID, stunServers);
33
11/19/2013

34. API Example – Media Streams
window.webkitURL.createObjectURL.UC.phone.onRemoteMediaStream = function(remoteMediaStream) {
//Configure the streams, this can be used to set up visibility of elements and
//set the elements src to that of the remote stream, the remoteMediaStream must be
//added to the page in order to receive audio or and video.
video.src = window.webkitURL.createObjectURL(remoteMediaStream);
};
UC.phone.onLocalMediaStream = function(localMediaStream) {
//As with the remote media stream, you should add the localMediaStream to the page
//in order to allow the framework to playback local (ie, webcam) feedback
preview.src = window.webkitURL.createObjectURL(localMediaStream);
};
34
11/19/2013

35. API Example – Make Call
var call;
//A method to call from the UI to make a call
function makeCall(addressToCall) {
//Create a call object from the framework and save it somewhere
call = UC.phone.createCall(addressToCall);
//Set what to do when the remote party ends the call
call.onEnded = function() { alert("Call Ended"); };
//Set up what to do if the callee is busy, inform your user etc
call.onBusy = function() { alert("The callee was busy"); };
//Dial the call
call.dial();
};
//A method to call from the UI to end a current call
function endCall() { call.end(); };
35
11/19/2013

36. Rod Apeldoorn
EasyRTC Server Lead
Priologic
CUSTOM SIGNALING
36
11/19/2013

37. Benefits Over SIP
• Faster on the client side
• Easier for developers to understand
• Less restrictive
37
11/19/2013

38. Example Custom Message Types
(from EasyRTC)
WebRTC Core
•
•
•
•
candidate
offer
answer
reject
Application Level
• authenticate
• hangup
• getIceConfig
• roomJoin
• roomData
• setPresence
• filesOffer
• Many more…
38
11/19/2013

39. Why Combine WebRTC Signaling with
Application Servers?
•
•
•
•
•
Authentication
Call logging
Call control
Combine with application logic
Client connects to just one server
– Why SIP + Presence + Application servers?
• Will SIP Gateways offer JSON signaling? Yes!
39
11/19/2013

40. Transports
Websockets
XHR Polling
•
•
•
•
• AKA “HTTP Long Polling”
• Easy + Securable
• To use:
Available in all modern browsers
Fast + Responsive + Securable
Maintains open socket
Servers have to deal with
concurrent socket limits
– XMLHttpRequest API
– jquery.ajax()
• Used by Google AppRTC Demo
40
11/19/2013

41. Transports
JSONP + CORS
Other
• The original popular method for
DHTML
• Cross site scripting issues
• “Cross-Origin Resource Sharing”
can be setup
• Still a valid fallback
• XMPP (Jabber)
– Especially for older browsers
– Instant messengers
• Local
– Bluetooth
– USB / Serial
• WebRTC Data Channels
– Example coming!
41
11/19/2013

42. Cisco Jabber + EasyRTC
• Cisco DX650 chat with Cisco
or Non-Cisco web user
• WebRTC Across Devices and
Transports
• Built using
– Cisco Jabber SDK
– EasyRTC Opensource
42
11/19/2013

43. Using a Websocket Library
General Benefits
Why EasyRTC uses Socket.io
• Cross browser support
• Easy message sending
• Easy event handling
• Most popular for Node.js
• Client API’s in many languages
– Connect / Disconnect / Message
• Fallbacks to XHR or JSONP
– JavaScript / C++ / ObjC / Java …
• Message Acknowledgments
• Why recode what’s done well?
43
11/19/2013

44. Private WebRTC Signaling
1.
2.
3.
Connect users to
servers via
Websockets
Establish
DataChannels
between users on
same servers
Establish WebRTC
Peer Connection
between User 1 and 3
–
–
–
Signals sent via
DataChannel
User 2 acts as a relay
Neither server aware
of final connection
44
11/19/2013

45. Private WebRTC Signaling
1.
2.
3.
Connect users to
servers via
Websockets
Establish
DataChannels
between users on
same servers
Establish WebRTC
Peer Connection
between User 1 and 3
–
–
–
Signals sent via
DataChannel
User 2 acts as a relay
Neither server aware
of final connection
45
11/19/2013

46. Private WebRTC Signaling
1.
2.
3.
Connect users to
servers via
Websockets
Establish
DataChannels
between users on
same servers
Establish WebRTC
Peer Connection
between User 1 and 3
–
–
–
http://bit.ly/1iq6v8D
Signals sent via
DataChannel
User 2 acts as a relay
Neither server aware
of final connection
46
11/19/2013

47. Q&A
47
11/19/2013