Embed Size (px)
Citation preview
Put some Web in your RTCSIP Architecture with Janus
Lorenzo Miniero@elminiero
OpenSIPS SummitApril 30th 2019,
“By The Power Of VoIP!”
Lorenzo Miniero• Ph.D @ UniNA• Chairman @ Meetecho• Barber shop avoider
Contacts and info• [email protected]• https://twitter.com/elminiero• https://www.slideshare.net/LorenzoMiniero
A few words on Meetecho
• Co-founded in 2009 as an academic spin-off• University research efforts brought to the market• Completely independent from the University
• Focus on real-time multimedia applications• Strong perspective on standardization and open source
• Several activities• Consulting services• Commercial support and Janus licenses• Streaming of live events (IETF, ACM, etc.)
• Proudly brewed in sunny Napoli(*), Italy
((*)You may have heard of it)
Why SIP and WebRTC?
• A lot of reasons why it makes sense to use WebRTC and SIP together• WebRTC stacks are avalailable everywhere, so making clients is easier now• Almost all of you have a SIP infrastructure already, and want to reuse it• SIP and WebRTC are similar enough that gatewaying isn’t impossible
• PSTN integration is a common scenario• “Hey granma, I’m calling from my browser!”
• Contact centers can really benefit from that• It’s much easier for customers to get in touch (button on the website)• It’s much easier to remotize agents (they just need a browser)• Re-using existing infrastructure saves a lot of money
• SIP-based conferencing can be enhanced too• e.g., audio conferencing involving WebRTC and PSTN users• ... maybe with video only for WebRTC users? (hybrid approach)• ... or, why not, video for everyone with the help of an MCU
Why SIP and WebRTC?
• A lot of reasons why it makes sense to use WebRTC and SIP together• WebRTC stacks are avalailable everywhere, so making clients is easier now• Almost all of you have a SIP infrastructure already, and want to reuse it• SIP and WebRTC are similar enough that gatewaying isn’t impossible
• PSTN integration is a common scenario• “Hey granma, I’m calling from my browser!”
• Contact centers can really benefit from that• It’s much easier for customers to get in touch (button on the website)• It’s much easier to remotize agents (they just need a browser)• Re-using existing infrastructure saves a lot of money
• SIP-based conferencing can be enhanced too• e.g., audio conferencing involving WebRTC and PSTN users• ... maybe with video only for WebRTC users? (hybrid approach)• ... or, why not, video for everyone with the help of an MCU
Why SIP and WebRTC?
• A lot of reasons why it makes sense to use WebRTC and SIP together• WebRTC stacks are avalailable everywhere, so making clients is easier now• Almost all of you have a SIP infrastructure already, and want to reuse it• SIP and WebRTC are similar enough that gatewaying isn’t impossible
• PSTN integration is a common scenario• “Hey granma, I’m calling from my browser!”
• Contact centers can really benefit from that• It’s much easier for customers to get in touch (button on the website)• It’s much easier to remotize agents (they just need a browser)• Re-using existing infrastructure saves a lot of money
• SIP-based conferencing can be enhanced too• e.g., audio conferencing involving WebRTC and PSTN users• ... maybe with video only for WebRTC users? (hybrid approach)• ... or, why not, video for everyone with the help of an MCU
Why SIP and WebRTC?
• A lot of reasons why it makes sense to use WebRTC and SIP together• WebRTC stacks are avalailable everywhere, so making clients is easier now• Almost all of you have a SIP infrastructure already, and want to reuse it• SIP and WebRTC are similar enough that gatewaying isn’t impossible
• PSTN integration is a common scenario• “Hey granma, I’m calling from my browser!”
• Contact centers can really benefit from that• It’s much easier for customers to get in touch (button on the website)• It’s much easier to remotize agents (they just need a browser)• Re-using existing infrastructure saves a lot of money
• SIP-based conferencing can be enhanced too• e.g., audio conferencing involving WebRTC and PSTN users• ... maybe with video only for WebRTC users? (hybrid approach)• ... or, why not, video for everyone with the help of an MCU
Sometimes it’s not that easy, though...
Try adding WebRTC support to THAT!
How similar are SIP and WebRTC?
How similar are SIP and WebRTC?
The WebRTC protocol suite: scary!
• Signalling (well, sort of) and Negotiation• Javascript Session Establishment Protocol (JSEP)• Session Description Protocol (SDP) adaptation
• Connection Establishment and NAT Traversal• Session Traversal Utilities for NAT (STUN)• Traversal Using Relay NAT (TURN)• Interactive Connectivity Establishment (ICE)
• Media Transport and Control• Real-time Transport (and Control) Protocol (RTP/RTCP)• Secure Extensions to RTP (SRTP)• Datagram Transport Layer Security (DTLS)
• Multimedia codecs• Opus audio codec (MTI, Mandatory-to-implement)• VP8 and H.264 video codecs (MTI, Mandatory-to-implement)
• Generic Data• WebRTC Data Channels (SCTP)
The WebRTC protocol suite: scary!
• Signalling (well, sort of) and Negotiation• Javascript Session Establishment Protocol (JSEP)• Session Description Protocol (SDP) adaptation
• Connection Establishment and NAT Traversal• Session Traversal Utilities for NAT (STUN)• Traversal Using Relay NAT (TURN)• Interactive Connectivity Establishment (ICE)
• Media Transport and Control• Real-time Transport (and Control) Protocol (RTP/RTCP)• Secure Extensions to RTP (SRTP)• Datagram Transport Layer Security (DTLS)
• Multimedia codecs• Opus audio codec (MTI, Mandatory-to-implement)• VP8 and H.264 video codecs (MTI, Mandatory-to-implement)
• Generic Data• WebRTC Data Channels (SCTP)
The WebRTC protocol suite: scary!
• Signalling (well, sort of) and Negotiation• Javascript Session Establishment Protocol (JSEP)• Session Description Protocol (SDP) adaptation
• Connection Establishment and NAT Traversal• Session Traversal Utilities for NAT (STUN)• Traversal Using Relay NAT (TURN)• Interactive Connectivity Establishment (ICE)
• Media Transport and Control• Real-time Transport (and Control) Protocol (RTP/RTCP)• Secure Extensions to RTP (SRTP)• Datagram Transport Layer Security (DTLS)
• Multimedia codecs• Opus audio codec (MTI, Mandatory-to-implement)• VP8 and H.264 video codecs (MTI, Mandatory-to-implement)
• Generic Data• WebRTC Data Channels (SCTP)
The WebRTC protocol suite: scary!
• Signalling (well, sort of) and Negotiation• Javascript Session Establishment Protocol (JSEP)• Session Description Protocol (SDP) adaptation
• Connection Establishment and NAT Traversal• Session Traversal Utilities for NAT (STUN)• Traversal Using Relay NAT (TURN)• Interactive Connectivity Establishment (ICE)
• Media Transport and Control• Real-time Transport (and Control) Protocol (RTP/RTCP)• Secure Extensions to RTP (SRTP)• Datagram Transport Layer Security (DTLS)
• Multimedia codecs• Opus audio codec (MTI, Mandatory-to-implement)• VP8 and H.264 video codecs (MTI, Mandatory-to-implement)
• Generic Data• WebRTC Data Channels (SCTP)
Talking to a server instead
Talking to a server instead
Talking to a server instead
... maybe SIP and other stuff as well!
... maybe SIP and other stuff as well!
... maybe SIP and other stuff as well!
Enter Janus!
JanusGeneral purpose, open source WebRTC server
• https://github.com/meetecho/janus-gateway• Demos and documentation: https://janus.conf.meetecho.com• Community: https://groups.google.com/forum/#!forum/meetecho-janus
Modular architecture
• The core only implements the WebRTC stack• JSEP/SDP, ICE, DTLS-SRTP, Data Channels, Simulcast, VP9-SVC, ...
• Plugins expose Janus API over different “transports”• Currently HTTP / WebSockets / RabbitMQ / Unix Sockets / MQTT / Nanomsg
• “Application” logic implemented in plugins too• Users attach to plugins via the Janus core• The core handles the WebRTC stuff• Plugins route/manipulate the media/data
• Plugins can be combined on client side as “bricks”• Video SFU, Audio MCU, SIP gatewaying, broadcasting, etc.
Modular architecture
• The core only implements the WebRTC stack• JSEP/SDP, ICE, DTLS-SRTP, Data Channels, Simulcast, VP9-SVC, ...
• Plugins expose Janus API over different “transports”• Currently HTTP / WebSockets / RabbitMQ / Unix Sockets / MQTT / Nanomsg
• “Application” logic implemented in plugins too• Users attach to plugins via the Janus core• The core handles the WebRTC stuff• Plugins route/manipulate the media/data
• Plugins can be combined on client side as “bricks”• Video SFU, Audio MCU, SIP gatewaying, broadcasting, etc.
Modular architecture
• The core only implements the WebRTC stack• JSEP/SDP, ICE, DTLS-SRTP, Data Channels, Simulcast, VP9-SVC, ...
• Plugins expose Janus API over different “transports”• Currently HTTP / WebSockets / RabbitMQ / Unix Sockets / MQTT / Nanomsg
• “Application” logic implemented in plugins too• Users attach to plugins via the Janus core• The core handles the WebRTC stuff• Plugins route/manipulate the media/data
• Plugins can be combined on client side as “bricks”• Video SFU, Audio MCU, SIP gatewaying, broadcasting, etc.
Modular architecture
• The core only implements the WebRTC stack• JSEP/SDP, ICE, DTLS-SRTP, Data Channels, Simulcast, VP9-SVC, ...
• Plugins expose Janus API over different “transports”• Currently HTTP / WebSockets / RabbitMQ / Unix Sockets / MQTT / Nanomsg
• “Application” logic implemented in plugins too• Users attach to plugins via the Janus core• The core handles the WebRTC stuff• Plugins route/manipulate the media/data
• Plugins can be combined on client side as “bricks”• Video SFU, Audio MCU, SIP gatewaying, broadcasting, etc.
Extensible Architecture and API
Extensible Architecture and API
Janus + SIP = r
• Since day one, SIP support has been available as a Janus plugin• Demo: https://janus.conf.meetecho.com/siptest
• Basically a WebRTC-to/from-SIP gateway• WebRTC on one side, SIP(S)/(S)RTP on the other end
• Janus SIP plugin acts as a SIP endpoint• SIP stack implemented with Sofia-SIP• WebRTC users only see the Janus API (JSON)• No transcoding, media is only relayed• Built-in recording (separate media legs)
• Simplifies life for web developers• No need to worry about a SIP stack (only SIP URIs)• Basic methods/events to handle call (call, answer, hangup)• Allows headers injection (REGISTER, INVITE)
Janus + SIP = r
• Since day one, SIP support has been available as a Janus plugin• Demo: https://janus.conf.meetecho.com/siptest
• Basically a WebRTC-to/from-SIP gateway• WebRTC on one side, SIP(S)/(S)RTP on the other end
• Janus SIP plugin acts as a SIP endpoint• SIP stack implemented with Sofia-SIP• WebRTC users only see the Janus API (JSON)• No transcoding, media is only relayed• Built-in recording (separate media legs)
• Simplifies life for web developers• No need to worry about a SIP stack (only SIP URIs)• Basic methods/events to handle call (call, answer, hangup)• Allows headers injection (REGISTER, INVITE)
Janus + SIP = r
• Since day one, SIP support has been available as a Janus plugin• Demo: https://janus.conf.meetecho.com/siptest
• Basically a WebRTC-to/from-SIP gateway• WebRTC on one side, SIP(S)/(S)RTP on the other end
• Janus SIP plugin acts as a SIP endpoint• SIP stack implemented with Sofia-SIP• WebRTC users only see the Janus API (JSON)• No transcoding, media is only relayed• Built-in recording (separate media legs)
• Simplifies life for web developers• No need to worry about a SIP stack (only SIP URIs)• Basic methods/events to handle call (call, answer, hangup)• Allows headers injection (REGISTER, INVITE)
Janus + SIP = r
• Since day one, SIP support has been available as a Janus plugin• Demo: https://janus.conf.meetecho.com/siptest
• Basically a WebRTC-to/from-SIP gateway• WebRTC on one side, SIP(S)/(S)RTP on the other end
• Janus SIP plugin acts as a SIP endpoint• SIP stack implemented with Sofia-SIP• WebRTC users only see the Janus API (JSON)• No transcoding, media is only relayed• Built-in recording (separate media legs)
• Simplifies life for web developers• No need to worry about a SIP stack (only SIP URIs)• Basic methods/events to handle call (call, answer, hangup)• Allows headers injection (REGISTER, INVITE)
The SIP plugin in a nutshell
Is SIP in the browser always a good idea?
• Most WebRTC gateways require you to do SIP in the browser• SIP over WebSockets (e.g., via JsSIP)
• We explained how the Janus SIP plugin does SIP internally, instead• A SIP stack is created for each new user• The client exchanges messages via a JSON-based API
• There are indeed reasons why you may NOT want SIP in the browser...1 SIP infrastructure can be completely clueless about WebRTC2 Handling a whole SIP stack on the client side can be troublesome3 Using a simpler JSON API makes it easier for web developers4 Wrapping SIP helps protecting from “well known” attacks (e.g., vulnerabilities)5 Much easier to make “assumptions” on the traffic you’ll handle6 Masking SIP also helps hiding the topology of the SIP infrastructure
Is SIP in the browser always a good idea?
• Most WebRTC gateways require you to do SIP in the browser• SIP over WebSockets (e.g., via JsSIP)
• We explained how the Janus SIP plugin does SIP internally, instead• A SIP stack is created for each new user• The client exchanges messages via a JSON-based API
• There are indeed reasons why you may NOT want SIP in the browser...1 SIP infrastructure can be completely clueless about WebRTC2 Handling a whole SIP stack on the client side can be troublesome3 Using a simpler JSON API makes it easier for web developers4 Wrapping SIP helps protecting from “well known” attacks (e.g., vulnerabilities)5 Much easier to make “assumptions” on the traffic you’ll handle6 Masking SIP also helps hiding the topology of the SIP infrastructure
Is SIP in the browser always a good idea?
• Most WebRTC gateways require you to do SIP in the browser• SIP over WebSockets (e.g., via JsSIP)
• We explained how the Janus SIP plugin does SIP internally, instead• A SIP stack is created for each new user• The client exchanges messages via a JSON-based API
• There are indeed reasons why you may NOT want SIP in the browser...1 SIP infrastructure can be completely clueless about WebRTC2 Handling a whole SIP stack on the client side can be troublesome3 Using a simpler JSON API makes it easier for web developers4 Wrapping SIP helps protecting from “well known” attacks (e.g., vulnerabilities)5 Much easier to make “assumptions” on the traffic you’ll handle6 Masking SIP also helps hiding the topology of the SIP infrastructure
Is SIP in the browser always a good idea?
• Most WebRTC gateways require you to do SIP in the browser• SIP over WebSockets (e.g., via JsSIP)
• We explained how the Janus SIP plugin does SIP internally, instead• A SIP stack is created for each new user• The client exchanges messages via a JSON-based API
• There are indeed reasons why you may NOT want SIP in the browser...1 SIP infrastructure can be completely clueless about WebRTC2 Handling a whole SIP stack on the client side can be troublesome3 Using a simpler JSON API makes it easier for web developers4 Wrapping SIP helps protecting from “well known” attacks (e.g., vulnerabilities)5 Much easier to make “assumptions” on the traffic you’ll handle6 Masking SIP also helps hiding the topology of the SIP infrastructure
Is SIP in the browser always a good idea?
• Most WebRTC gateways require you to do SIP in the browser• SIP over WebSockets (e.g., via JsSIP)
• We explained how the Janus SIP plugin does SIP internally, instead• A SIP stack is created for each new user• The client exchanges messages via a JSON-based API
• There are indeed reasons why you may NOT want SIP in the browser...1 SIP infrastructure can be completely clueless about WebRTC2 Handling a whole SIP stack on the client side can be troublesome3 Using a simpler JSON API makes it easier for web developers4 Wrapping SIP helps protecting from “well known” attacks (e.g., vulnerabilities)5 Much easier to make “assumptions” on the traffic you’ll handle6 Masking SIP also helps hiding the topology of the SIP infrastructure
Is SIP in the browser always a good idea?
• Most WebRTC gateways require you to do SIP in the browser• SIP over WebSockets (e.g., via JsSIP)
• We explained how the Janus SIP plugin does SIP internally, instead• A SIP stack is created for each new user• The client exchanges messages via a JSON-based API
• There are indeed reasons why you may NOT want SIP in the browser...1 SIP infrastructure can be completely clueless about WebRTC2 Handling a whole SIP stack on the client side can be troublesome3 Using a simpler JSON API makes it easier for web developers4 Wrapping SIP helps protecting from “well known” attacks (e.g., vulnerabilities)5 Much easier to make “assumptions” on the traffic you’ll handle6 Masking SIP also helps hiding the topology of the SIP infrastructure
Is SIP in the browser always a good idea?
• Most WebRTC gateways require you to do SIP in the browser• SIP over WebSockets (e.g., via JsSIP)
• We explained how the Janus SIP plugin does SIP internally, instead• A SIP stack is created for each new user• The client exchanges messages via a JSON-based API
• There are indeed reasons why you may NOT want SIP in the browser...1 SIP infrastructure can be completely clueless about WebRTC2 Handling a whole SIP stack on the client side can be troublesome3 Using a simpler JSON API makes it easier for web developers4 Wrapping SIP helps protecting from “well known” attacks (e.g., vulnerabilities)5 Much easier to make “assumptions” on the traffic you’ll handle6 Masking SIP also helps hiding the topology of the SIP infrastructure
Is SIP in the browser always a good idea?
• Most WebRTC gateways require you to do SIP in the browser• SIP over WebSockets (e.g., via JsSIP)
• We explained how the Janus SIP plugin does SIP internally, instead• A SIP stack is created for each new user• The client exchanges messages via a JSON-based API
• There are indeed reasons why you may NOT want SIP in the browser...1 SIP infrastructure can be completely clueless about WebRTC2 Handling a whole SIP stack on the client side can be troublesome3 Using a simpler JSON API makes it easier for web developers4 Wrapping SIP helps protecting from “well known” attacks (e.g., vulnerabilities)5 Much easier to make “assumptions” on the traffic you’ll handle6 Masking SIP also helps hiding the topology of the SIP infrastructure
Is SIP in the browser always a good idea?
• Most WebRTC gateways require you to do SIP in the browser• SIP over WebSockets (e.g., via JsSIP)
• We explained how the Janus SIP plugin does SIP internally, instead• A SIP stack is created for each new user• The client exchanges messages via a JSON-based API
• There are indeed reasons why you may NOT want SIP in the browser...1 SIP infrastructure can be completely clueless about WebRTC2 Handling a whole SIP stack on the client side can be troublesome3 Using a simpler JSON API makes it easier for web developers4 Wrapping SIP helps protecting from “well known” attacks (e.g., vulnerabilities)5 Much easier to make “assumptions” on the traffic you’ll handle6 Masking SIP also helps hiding the topology of the SIP infrastructure
Using the SIP plugin in Janus instead
Using the SIP plugin in Janus instead
What if you DO want SIP in the browser?
• You may want to have more control on SIP messaging• e.g., to re-use stacks like JsSIP or SIP.js instead of JSON, or other reasons
• The SIP plugin doesn’t allow for that• Complexity hidden from users, on purpose• Only partial control (e.g., custom headers, INFO DTMF, negotiating security)
• NoSIP plugin to the rescue!• Different Janus plugin that doesn’t care about signalling, only SDP
• You pass it a WebRTC SDP, it gives back a plain SDP• You pass it a plain SDP, it gives back a WebRTC SDP
• Plugin bridges the media between WebRTC user and legacy client• No "register", "call", etc., that’s up to you (e.g., SIP or others)
What if you DO want SIP in the browser?
• You may want to have more control on SIP messaging• e.g., to re-use stacks like JsSIP or SIP.js instead of JSON, or other reasons
• The SIP plugin doesn’t allow for that• Complexity hidden from users, on purpose• Only partial control (e.g., custom headers, INFO DTMF, negotiating security)
• NoSIP plugin to the rescue!• Different Janus plugin that doesn’t care about signalling, only SDP
• You pass it a WebRTC SDP, it gives back a plain SDP• You pass it a plain SDP, it gives back a WebRTC SDP
• Plugin bridges the media between WebRTC user and legacy client• No "register", "call", etc., that’s up to you (e.g., SIP or others)
What if you DO want SIP in the browser?
• You may want to have more control on SIP messaging• e.g., to re-use stacks like JsSIP or SIP.js instead of JSON, or other reasons
• The SIP plugin doesn’t allow for that• Complexity hidden from users, on purpose• Only partial control (e.g., custom headers, INFO DTMF, negotiating security)
• NoSIP plugin to the rescue!• Different Janus plugin that doesn’t care about signalling, only SDP
• You pass it a WebRTC SDP, it gives back a plain SDP• You pass it a plain SDP, it gives back a WebRTC SDP
• Plugin bridges the media between WebRTC user and legacy client• No "register", "call", etc., that’s up to you (e.g., SIP or others)
What if you DO want SIP in the browser?
• You may want to have more control on SIP messaging• e.g., to re-use stacks like JsSIP or SIP.js instead of JSON, or other reasons
• The SIP plugin doesn’t allow for that• Complexity hidden from users, on purpose• Only partial control (e.g., custom headers, INFO DTMF, negotiating security)
• NoSIP plugin to the rescue!• Different Janus plugin that doesn’t care about signalling, only SDP
• You pass it a WebRTC SDP, it gives back a plain SDP• You pass it a plain SDP, it gives back a WebRTC SDP
• Plugin bridges the media between WebRTC user and legacy client• No "register", "call", etc., that’s up to you (e.g., SIP or others)
What if you DO want SIP in the browser?
• You may want to have more control on SIP messaging• e.g., to re-use stacks like JsSIP or SIP.js instead of JSON, or other reasons
• The SIP plugin doesn’t allow for that• Complexity hidden from users, on purpose• Only partial control (e.g., custom headers, INFO DTMF, negotiating security)
• NoSIP plugin to the rescue!• Different Janus plugin that doesn’t care about signalling, only SDP
• You pass it a WebRTC SDP, it gives back a plain SDP• You pass it a plain SDP, it gives back a WebRTC SDP
• Plugin bridges the media between WebRTC user and legacy client• No "register", "call", etc., that’s up to you (e.g., SIP or others)
What if you DO want SIP in the browser?
• You may want to have more control on SIP messaging• e.g., to re-use stacks like JsSIP or SIP.js instead of JSON, or other reasons
• The SIP plugin doesn’t allow for that• Complexity hidden from users, on purpose• Only partial control (e.g., custom headers, INFO DTMF, negotiating security)
• NoSIP plugin to the rescue!• Different Janus plugin that doesn’t care about signalling, only SDP
• You pass it a WebRTC SDP, it gives back a plain SDP• You pass it a plain SDP, it gives back a WebRTC SDP
• Plugin bridges the media between WebRTC user and legacy client• No "register", "call", etc., that’s up to you (e.g., SIP or others)
Using the NoSIP plugin in practice
Using the NoSIP plugin in practice
How scalable is all this?
• Did a talk on Janus scalability just last year, at CommCon• https://2018.commcon.xyz/speakers/lorenzo-miniero/• https://www.youtube.com/watch?v=zxRwELmyWU0&t=264s
• Recently did many measurements on Janus in general as well• https://janus.conf.meetecho.com/citeus
• So how easy is to scale the SIP plugin? Quite easy, actually!
1 Load increase is pretty much linear2 Caller and callee are independent of each other (tied by SIP infrastructure)3 Very easy to spawn new instances on a per-need basis4 Different strategies possible depending on how load balancing needs to be done
How scalable is all this?
• Did a talk on Janus scalability just last year, at CommCon• https://2018.commcon.xyz/speakers/lorenzo-miniero/• https://www.youtube.com/watch?v=zxRwELmyWU0&t=264s
• Recently did many measurements on Janus in general as well• https://janus.conf.meetecho.com/citeus
• So how easy is to scale the SIP plugin? Quite easy, actually!
1 Load increase is pretty much linear2 Caller and callee are independent of each other (tied by SIP infrastructure)3 Very easy to spawn new instances on a per-need basis4 Different strategies possible depending on how load balancing needs to be done
How scalable is all this?
• Did a talk on Janus scalability just last year, at CommCon• https://2018.commcon.xyz/speakers/lorenzo-miniero/• https://www.youtube.com/watch?v=zxRwELmyWU0&t=264s
• Recently did many measurements on Janus in general as well• https://janus.conf.meetecho.com/citeus
• So how easy is to scale the SIP plugin? Quite easy, actually!
1 Load increase is pretty much linear2 Caller and callee are independent of each other (tied by SIP infrastructure)3 Very easy to spawn new instances on a per-need basis4 Different strategies possible depending on how load balancing needs to be done
How scalable is all this?
• Did a talk on Janus scalability just last year, at CommCon• https://2018.commcon.xyz/speakers/lorenzo-miniero/• https://www.youtube.com/watch?v=zxRwELmyWU0&t=264s
• Recently did many measurements on Janus in general as well• https://janus.conf.meetecho.com/citeus
• So how easy is to scale the SIP plugin? Quite easy, actually!
1 Load increase is pretty much linear2 Caller and callee are independent of each other (tied by SIP infrastructure)3 Very easy to spawn new instances on a per-need basis4 Different strategies possible depending on how load balancing needs to be done
How scalable is all this?
• Did a talk on Janus scalability just last year, at CommCon• https://2018.commcon.xyz/speakers/lorenzo-miniero/• https://www.youtube.com/watch?v=zxRwELmyWU0&t=264s
• Recently did many measurements on Janus in general as well• https://janus.conf.meetecho.com/citeus
• So how easy is to scale the SIP plugin? Quite easy, actually!
1 Load increase is pretty much linear2 Caller and callee are independent of each other (tied by SIP infrastructure)3 Very easy to spawn new instances on a per-need basis4 Different strategies possible depending on how load balancing needs to be done
How scalable is all this?
• Did a talk on Janus scalability just last year, at CommCon• https://2018.commcon.xyz/speakers/lorenzo-miniero/• https://www.youtube.com/watch?v=zxRwELmyWU0&t=264s
• Recently did many measurements on Janus in general as well• https://janus.conf.meetecho.com/citeus
• So how easy is to scale the SIP plugin? Quite easy, actually!
1 Load increase is pretty much linear2 Caller and callee are independent of each other (tied by SIP infrastructure)3 Very easy to spawn new instances on a per-need basis4 Different strategies possible depending on how load balancing needs to be done
How scalable is all this?
• Did a talk on Janus scalability just last year, at CommCon• https://2018.commcon.xyz/speakers/lorenzo-miniero/• https://www.youtube.com/watch?v=zxRwELmyWU0&t=264s
• Recently did many measurements on Janus in general as well• https://janus.conf.meetecho.com/citeus
• So how easy is to scale the SIP plugin? Quite easy, actually!
1 Load increase is pretty much linear2 Caller and callee are independent of each other (tied by SIP infrastructure)3 Very easy to spawn new instances on a per-need basis4 Different strategies possible depending on how load balancing needs to be done
Different scalability and HA strategies
Different scalability and HA strategies
Different scalability and HA strategies
Different scalability and HA strategies
Did I mention Janus works great with HOMER?
https://www.opensips.org/events/Summit-2018Amsterdam/
Next steps
• While basically complete, the SIP plugin could use some enhancements
• No support for blind/attended transfers yet, for instance
• Additional security, e.g., via authenticated headers
• A SIP trunking mode might also help
• Maybe multiple active calls at the same time on the same PeerConnection?
• Lawful Interception is a commonly asked feature as well
Your application here!• Janus SIP plugin already used in production by many• Play with it and see if it can help you too!
Next steps
• While basically complete, the SIP plugin could use some enhancements
• No support for blind/attended transfers yet, for instance
• Additional security, e.g., via authenticated headers
• A SIP trunking mode might also help
• Maybe multiple active calls at the same time on the same PeerConnection?
• Lawful Interception is a commonly asked feature as well
Your application here!• Janus SIP plugin already used in production by many• Play with it and see if it can help you too!
Thanks! Questions? Comments?
Get in touch!• https://twitter.com/elminiero• https://twitter.com/meetecho• http://www.meetecho.com
