The document discusses the importance of WebRTC interoperability. It argues that while some applications do not require interoperability, many applications that are high-value, such as conferencing, education, and telemedicine, do require interoperability. The document also discusses signalling protocols for WebRTC, arguing that SIP provides the widest interoperability choices today through various open-source browser and server implementations. It provides examples of using SIP over WebSockets with the Kamailio server to enable interoperability.
2. WebRTC Interoperability
and why it is important
Peter Dunkley
Technical Director, Crocodile RCS Ltd
Email: peter.dunkley@crocodilertc.net
Twitter: @pdunkley
4. 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
5. 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
6. 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
7. 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
8. 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.
11. 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.
12. 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.
http://tools.ietf.org/html/draft-johansson-dane-sip-00
• 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.
13. 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.
14. With a gateway
UA
SIP and RTP
Gateway
Single point of failure
(unless complex and
expensive dialog
replication is used)
SIP and RTP
UA
15. Without a gateway
SIP Proxy
UA
Resilience without
replication (transaction
stateful proxy as per
RFC 3261)
RTP
UA
16. 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
17. 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.
18. 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", "", "");
}
19. 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();
}
...
20. Example: SIP over WebSockets in Kamailio
onreply_route {
if ((proto == WS || proto == WSS)
&& status =~ “[12][0-9][0-9]”) {
add_contact_alias();
}
}
21. 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);
}
}
...
22. 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));
}
}
...
23. 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