webrtc summit november 2013 - webrtc interoperability (and why it is important)
DESCRIPTION
A presentation by Peter Dunkley (Technical Director, Crocodile RCS Ltd). Presentation date 6-Nov-2013.TRANSCRIPT
1
WebRTC Interoperability
WebRTC Interoperability and why it is important
Peter Dunkley
Technical Director, Crocodile RCS Ltd
Email: [email protected] Twitter: @pdunkley
Busting the interoperability myths
• WebRTC doesn’t need to/shouldn’t interoperate – Interoperability (for browsers) has been in the charter from the beginning.
– PSTN interoperability has always been a concern (if not the primary objective) – why else make G.711 MTI for audio?
– Mobile/video interoperability has always been a concern (if not the primary objective) – why else have such a long an fierce debate over H.264 and VP8?
• Interoperability is bad for WebRTC because it is bad for business – Some applications do not require interoperability, and their business case
is actually harmed by it.
– Other applications require interoperability and their business case doesn’t exist without it.
• To interoperate or not should be a business decision
Many applications don’t need interoperability
• Online dating – you’d only expect to interact with people on the same site
• Online gambling – you’d only expect to interact with people on the same site
• Online gaming – you’d only expect to interact with people in the same game
• Collaboration within Google Docs or Office 365
Most interactive, browser-only, applications don’t need to interoperate
Many applications do need 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
Interoperability example: Call Centres
• WebRTC can make call centres run more efficiently
– No need for separate computers and hard-phones
– No need for complex soft-phone and web-UI integration
– Give everyone an inexpensive computer that boots into the browser and have a fully integrated web-app
• WebRTC can make calling a call centre less unpleasant
– Web-form instead of IVR
– Context based calling (no need to re-authenticate)
– Callers can be entertained while in the queue (games and YouTube videos)
The call centre needs to be accessible from the PSTN
Busting the signalling myths
• WebRTC doesn’t use signalling
– Of course it does – how else do you discover the IP address, ports, and codecs supported by your peer.
– Even a proprietary REST/json/WebSocket mash-up is signalling – just not standardised signalling.
• WebRTC will replace (or compete with) SIP
– WebRTC is about peer-to-peer media and data – signalling is left to the application developer.
– Many non-interoperable applications will use proprietary signalling.
– If you need to interoperate SIP is the signalling protocol of choice around the world today.
The signalling triangle (non-interoperable)
UA UA Media
Server
The signalling trapezoid (interoperable)
UA UA
Server Signalling
Media
Server
But SIP isn’t the only standard?
• Some people are using XMPP jingle for WebRTC – “Web people” tend to like XMPP and understand it better than SIP.
– If interoperability is not important there are better choices than XMPP (proprietary REST/json/WebSockets).
– If interoperability is important there are better choices than XMPP - to interoperate XMPP with most networks and media servers (which use SIP) you’d need a gateway.
• What about OpenPeer – A great idea and I think it will be big for interoperable, browser-only,
applications.
– To interoperate OpenPeer with most networks and media servers (which use SIP) you’d need a gateway.
Busting the SIP myths
• SIP is hard – Why do you care - you don’t plan to implement it yourself right?
• SIP is insecure – Many ITSPs choose not to secure SIP – they should be ashamed of
themselves.
– TLS support is included in RFC 3261 and has been refined since then.
– There is ongoing work today to improve SIP TLS support with DANE.
• The media profile of WebRTC (RTP/SAVPF) is not compatible with existing SIP equipment (RTP/AVP) – Media proxies can convert between the profiles without having to decode
and re-encode the media.
http://tools.ietf.org/html/draft-johansson-dane-sip-00
Interoperability choices for SIP signalling
• You have two choices for interoperability – Build interoperability into your application (in the Javascript running in the
browser).
– Build interoperability into your infrastructure (with a gateway in the network).
• It is better if you do not need gateways – This means interoperability in the application (SIP in the browser).
– The same logic used to promote H.264 (you’d need gateways in the network to interoperate) applies to the signalling channel.
– Gateways in the network are expensive
• More equipment to deploy.
• Resilience and failover is harder.
With a gateway
UA UA Gateway
Single point of failure (unless complex and expensive dialog replication is used)
SIP and RTP SIP and RTP
Without a gateway
UA UA
SIP Proxy
RTP
Resilience without replication (transaction stateful proxy as per RFC 3261)
SIP gives you the widest choice today
• There are many open-source server implementations of SIP over WebSockets
– Asterisk, FreeSwitch, Kamailio, OverSIP, reSIProcate
• There are many open-source client (Javascript) implementations of SIP over WebSockets
– JAIN-SIP-Javascript, JsSIP, QoffeeSIP, sipml5
• There are SDK and network vendors who are packaging this stuff to make it easy for you to use.
No other protocol has this level of support
What about a demo?
• This session has been presented from the UK using WebRTC
• Interoperable SIP signalling was used to establish the session
– JsSIP is used for the in-browser SIP client.
– Kamailio is the network SIP server.
• The same network can be used to make calls to the PSTN and to/from legacy SIP devices
– mediaproxy-ng converts between the RTP/SAVPF and RTP/AVP profile without decoding and re-encoding the media.
Example: SIP over WebSockets in Kamailio
...
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", "", "");
}
Example: SIP over WebSockets in Kamailio
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();
}
...
Example: SIP over WebSockets in Kamailio
onreply_route {
if ((proto == WS || proto == WSS)
&& status =~ “[12][0-9][0-9]”) {
add_contact_alias();
}
}
Example: SIP over WebSockets in Kamailio
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);
}
}
...
Example: SIP over WebSockets in Kamailio
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 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));
}
}
...
Final thought: identity federation is important
• Log on with your identity of choice
– Facebook, Google+, LinkedIn, OpenID, Twitter
• Identity federation can be done with SIP over WebSockets
– See auth_ephemeral in Kamailio
– There is no need to create and maintain SIP accounts
• When a user connects to your service using an federated identity you get read access to their profile – this has value
– For example, when a customer calls into your call centre you get to learn a lot more about them
Ephemeral Authentication
Web Service
SIP Proxy
Calling UA
Called UA
???
Shared secret – communication
link not required
You don’t have to create or manage accounts on the SIP Proxy/registrar
Example: Ephemeral authentication in Kamailio
...
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)”);
}
Example: Ephemeral authentication in Kamailio
...
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();
...
