SlideShare a Scribd company logo
1 of 48
Am I Sober Or Am I Trunk?
A Janus Story
Lorenzo Miniero
@lminiero@fosstodon.org
Kamailio World
April 19th 2024,
Who am I?
Lorenzo Miniero
• Ph.D @ UniNA
• Chairman @ Meetecho
• Main author of Janus
Contacts and info
• lorenzo@meetecho.com
• https://fosstodon.org/@lminiero
• https://www.meetecho.com
• https://lminiero.it
Just 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
A bit of context: Janus, WebRTC and SIP
Janus
General purpose, open source WebRTC server
• https://github.com/meetecho/janus-gateway
• Demos and documentation: https://janus.conf.meetecho.com
• Community: https://janus.discourse.group/
SIP plugin in Janus
https://janus.conf.meetecho.com/docs/sip
An endpoint of behalf of WebRTC users
• Janus SIP plugin acts as a collection of SIP endpoints, not a server/trunk
• SIP stack implemented with Sofia-SIP
• WebRTC users only see the Janus API (JSON), no SIP
• 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 dialogs (call, answer, hangup, message, etc.)
• Allows SIP headers injection in many requests
• Support for more advanced features too (e.g., hold, transfer, real-time text, etc.)
An endpoint of behalf of WebRTC users
• Janus SIP plugin acts as a collection of SIP endpoints, not a server/trunk
• SIP stack implemented with Sofia-SIP
• WebRTC users only see the Janus API (JSON), no SIP
• 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 dialogs (call, answer, hangup, message, etc.)
• Allows SIP headers injection in many requests
• Support for more advanced features too (e.g., hold, transfer, real-time text, etc.)
Works great with Kamailio!
Remember this silly demo from last year?
Different users = different SIP stacks
What if we DO want trunking, though?
What’s a trunk anyway?
• A lot of buzzwords out there!
• Tried googling “SIP trunk”
• A gazillion of commercial fluff, very little technical details
• Basically (don’t quote me on that!), the digital equivalent of old analogue lines
• A group of phone lines implemented with SIP
• A way to connect multiple channels to, e.g., a PBX
• But isn’t that what SIP allows for already?
• No hardware limitations as in PSTN
• It’s over IP, we can have as many channels as we want
What’s a trunk anyway?
• A lot of buzzwords out there!
• Tried googling “SIP trunk”
• A gazillion of commercial fluff, very little technical details
• Basically (don’t quote me on that!), the digital equivalent of old analogue lines
• A group of phone lines implemented with SIP
• A way to connect multiple channels to, e.g., a PBX
• But isn’t that what SIP allows for already?
• No hardware limitations as in PSTN
• It’s over IP, we can have as many channels as we want
What’s a trunk anyway?
• A lot of buzzwords out there!
• Tried googling “SIP trunk”
• A gazillion of commercial fluff, very little technical details
• Basically (don’t quote me on that!), the digital equivalent of old analogue lines
• A group of phone lines implemented with SIP
• A way to connect multiple channels to, e.g., a PBX
• But isn’t that what SIP allows for already?
• No hardware limitations as in PSTN
• It’s over IP, we can have as many channels as we want
What’s a trunk anyway?
• More formally (maybe?), a way to connect private and public domains
• e.g., a private PBX and the PSTN
• More in general, interconnection between two SIP servers?
• e.g., IP based peering (address:port)
• Possibly with authentication (SIP based? TLS?)
• That’s something Janus could benefit from, in some cases
• Ensure all outgoing calls from WebRTC users go through a specific server
• Ensure all incoming calls for WebRTC users come from a specific server
• May help get rid of registrations, when unneeded (e.g., contact center)
What’s a trunk anyway?
• More formally (maybe?), a way to connect private and public domains
• e.g., a private PBX and the PSTN
• More in general, interconnection between two SIP servers?
• e.g., IP based peering (address:port)
• Possibly with authentication (SIP based? TLS?)
• That’s something Janus could benefit from, in some cases
• Ensure all outgoing calls from WebRTC users go through a specific server
• Ensure all incoming calls for WebRTC users come from a specific server
• May help get rid of registrations, when unneeded (e.g., contact center)
What’s a trunk anyway?
• More formally (maybe?), a way to connect private and public domains
• e.g., a private PBX and the PSTN
• More in general, interconnection between two SIP servers?
• e.g., IP based peering (address:port)
• Possibly with authentication (SIP based? TLS?)
• That’s something Janus could benefit from, in some cases
• Ensure all outgoing calls from WebRTC users go through a specific server
• Ensure all incoming calls for WebRTC users come from a specific server
• May help get rid of registrations, when unneeded (e.g., contact center)
What’s a trunk anyway?
• More formally (maybe?), a way to connect private and public domains
• e.g., a private PBX and the PSTN
• More in general, interconnection between two SIP servers?
• e.g., IP based peering (address:port)
• Possibly with authentication (SIP based? TLS?)
• That’s something Janus could benefit from, in some cases
• Ensure all outgoing calls from WebRTC users go through a specific server
• Ensure all incoming calls for WebRTC users come from a specific server
• May help get rid of registrations, when unneeded (e.g., contact center)
What’s a trunk anyway?
• More formally (maybe?), a way to connect private and public domains
• e.g., a private PBX and the PSTN
• More in general, interconnection between two SIP servers?
• e.g., IP based peering (address:port)
• Possibly with authentication (SIP based? TLS?)
• That’s something Janus could benefit from, in some cases
• Ensure all outgoing calls from WebRTC users go through a specific server
• Ensure all incoming calls for WebRTC users come from a specific server
• May help get rid of registrations, when unneeded (e.g., contact center)
What’s a trunk anyway?
• More formally (maybe?), a way to connect private and public domains
• e.g., a private PBX and the PSTN
• More in general, interconnection between two SIP servers?
• e.g., IP based peering (address:port)
• Possibly with authentication (SIP based? TLS?)
• That’s something Janus could benefit from, in some cases
• Ensure all outgoing calls from WebRTC users go through a specific server
• Ensure all incoming calls for WebRTC users come from a specific server
• May help get rid of registrations, when unneeded (e.g., contact center)
How do we do that with Janus, though?
• As we said, Janus is a collection of endpoints, not a SIP server
• Setting an outbound proxy is easy (supported already)
• No way to limit incoming traffic too, though (users have their own bound address)
• In theory, a couple of potential approaches
1 Implement an internal proxy in Janus
2 Refactor the SIP plugin to allow a shared SIP stack
• Both approaches have pros and cons
• ... and headaches in terms of implementation details!
How do we do that with Janus, though?
• As we said, Janus is a collection of endpoints, not a SIP server
• Setting an outbound proxy is easy (supported already)
• No way to limit incoming traffic too, though (users have their own bound address)
• In theory, a couple of potential approaches
1 Implement an internal proxy in Janus
2 Refactor the SIP plugin to allow a shared SIP stack
• Both approaches have pros and cons
• ... and headaches in terms of implementation details!
How do we do that with Janus, though?
• As we said, Janus is a collection of endpoints, not a SIP server
• Setting an outbound proxy is easy (supported already)
• No way to limit incoming traffic too, though (users have their own bound address)
• In theory, a couple of potential approaches
1 Implement an internal proxy in Janus
2 Refactor the SIP plugin to allow a shared SIP stack
• Both approaches have pros and cons
• ... and headaches in terms of implementation details!
How do we do that with Janus, though?
• As we said, Janus is a collection of endpoints, not a SIP server
• Setting an outbound proxy is easy (supported already)
• No way to limit incoming traffic too, though (users have their own bound address)
• In theory, a couple of potential approaches
1 Implement an internal proxy in Janus
2 Refactor the SIP plugin to allow a shared SIP stack
• Both approaches have pros and cons
• ... and headaches in terms of implementation details!
How do we do that with Janus, though?
• As we said, Janus is a collection of endpoints, not a SIP server
• Setting an outbound proxy is easy (supported already)
• No way to limit incoming traffic too, though (users have their own bound address)
• In theory, a couple of potential approaches
1 Implement an internal proxy in Janus
2 Refactor the SIP plugin to allow a shared SIP stack
• Both approaches have pros and cons
• ... and headaches in terms of implementation details!
Implementing an internal proxy in Janus
• This was the first idea that came to mind, as in theory “simpler”
• Proxy implementing the trunking part
• Addressing calls based on SIP URI (which Janus knows even for unregistered users)
• PRO: No need to touch the existing Janus SIP code
• We can keep the “collection of endpoints” approach
• Stack simply uses the local proxy as outbound proxy
• Everything else remains the same
• CON: But it isn’t really simple, at all!
• Writing a proxy, even if internal, would be a huge undertaking!!
• Besides, it would be a “silent”, hidden and unneeded hop
Implementing an internal proxy in Janus
• This was the first idea that came to mind, as in theory “simpler”
• Proxy implementing the trunking part
• Addressing calls based on SIP URI (which Janus knows even for unregistered users)
• PRO: No need to touch the existing Janus SIP code
• We can keep the “collection of endpoints” approach
• Stack simply uses the local proxy as outbound proxy
• Everything else remains the same
• CON: But it isn’t really simple, at all!
• Writing a proxy, even if internal, would be a huge undertaking!!
• Besides, it would be a “silent”, hidden and unneeded hop
Implementing an internal proxy in Janus
• This was the first idea that came to mind, as in theory “simpler”
• Proxy implementing the trunking part
• Addressing calls based on SIP URI (which Janus knows even for unregistered users)
• PRO: No need to touch the existing Janus SIP code
• We can keep the “collection of endpoints” approach
• Stack simply uses the local proxy as outbound proxy
• Everything else remains the same
• CON: But it isn’t really simple, at all!
• Writing a proxy, even if internal, would be a huge undertaking!!
• Besides, it would be a “silent”, hidden and unneeded hop
Refactor the SIP plugin (shared SIP stack)
• What if we instead allow different Janus users to re-use the same Sofia-SIP stack?
• This SIP stack could implement the peering, and enforce an outbound proxy
• Incoming dialogs could be processed in terms of who they’re for
• Call is for User X −→ notify it to WebRTC User X
• CON: Does requite changes to the SIP plugin code
• Sofia event loop would not have 1-1 association with specific user
• Users management, interactions and cleanup would need to be updated too
• PRO: Would be much easier to implement than a full proxy, though
• And most importantly, wouldn’t add an unneeded hop in the process
Refactor the SIP plugin (shared SIP stack)
• What if we instead allow different Janus users to re-use the same Sofia-SIP stack?
• This SIP stack could implement the peering, and enforce an outbound proxy
• Incoming dialogs could be processed in terms of who they’re for
• Call is for User X −→ notify it to WebRTC User X
• CON: Does requite changes to the SIP plugin code
• Sofia event loop would not have 1-1 association with specific user
• Users management, interactions and cleanup would need to be updated too
• PRO: Would be much easier to implement than a full proxy, though
• And most importantly, wouldn’t add an unneeded hop in the process
Refactor the SIP plugin (shared SIP stack)
• What if we instead allow different Janus users to re-use the same Sofia-SIP stack?
• This SIP stack could implement the peering, and enforce an outbound proxy
• Incoming dialogs could be processed in terms of who they’re for
• Call is for User X −→ notify it to WebRTC User X
• CON: Does requite changes to the SIP plugin code
• Sofia event loop would not have 1-1 association with specific user
• Users management, interactions and cleanup would need to be updated too
• PRO: Would be much easier to implement than a full proxy, though
• And most importantly, wouldn’t add an unneeded hop in the process
A single stack to rule them all
https://github.com/meetecho/janus-gateway/tree/sip-trunk
A single stack to rule them all
https://github.com/meetecho/janus-gateway/tree/sip-trunk
Implementation details (and challenges)
1 Trunk has a dedicated structure (IP peering details)
2 Stack associated to a “fake” SIP plugin participant (the trunk)
3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403)
4 Users can choose “regular” stack or trunk stack (UI in SIP demo page)
5 Trunk users present their SIP URI but don’t register (local mapping)
6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user)
7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog)
8 Events for WebRTC users delegated to user thread (not to block shared loop)
Implementation details (and challenges)
1 Trunk has a dedicated structure (IP peering details)
2 Stack associated to a “fake” SIP plugin participant (the trunk)
3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403)
4 Users can choose “regular” stack or trunk stack (UI in SIP demo page)
5 Trunk users present their SIP URI but don’t register (local mapping)
6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user)
7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog)
8 Events for WebRTC users delegated to user thread (not to block shared loop)
Implementation details (and challenges)
1 Trunk has a dedicated structure (IP peering details)
2 Stack associated to a “fake” SIP plugin participant (the trunk)
3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403)
4 Users can choose “regular” stack or trunk stack (UI in SIP demo page)
5 Trunk users present their SIP URI but don’t register (local mapping)
6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user)
7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog)
8 Events for WebRTC users delegated to user thread (not to block shared loop)
Implementation details (and challenges)
1 Trunk has a dedicated structure (IP peering details)
2 Stack associated to a “fake” SIP plugin participant (the trunk)
3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403)
4 Users can choose “regular” stack or trunk stack (UI in SIP demo page)
5 Trunk users present their SIP URI but don’t register (local mapping)
6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user)
7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog)
8 Events for WebRTC users delegated to user thread (not to block shared loop)
Implementation details (and challenges)
1 Trunk has a dedicated structure (IP peering details)
2 Stack associated to a “fake” SIP plugin participant (the trunk)
3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403)
4 Users can choose “regular” stack or trunk stack (UI in SIP demo page)
5 Trunk users present their SIP URI but don’t register (local mapping)
6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user)
7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog)
8 Events for WebRTC users delegated to user thread (not to block shared loop)
Implementation details (and challenges)
1 Trunk has a dedicated structure (IP peering details)
2 Stack associated to a “fake” SIP plugin participant (the trunk)
3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403)
4 Users can choose “regular” stack or trunk stack (UI in SIP demo page)
5 Trunk users present their SIP URI but don’t register (local mapping)
6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user)
7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog)
8 Events for WebRTC users delegated to user thread (not to block shared loop)
Implementation details (and challenges)
1 Trunk has a dedicated structure (IP peering details)
2 Stack associated to a “fake” SIP plugin participant (the trunk)
3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403)
4 Users can choose “regular” stack or trunk stack (UI in SIP demo page)
5 Trunk users present their SIP URI but don’t register (local mapping)
6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user)
7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog)
8 Events for WebRTC users delegated to user thread (not to block shared loop)
Implementation details (and challenges)
1 Trunk has a dedicated structure (IP peering details)
2 Stack associated to a “fake” SIP plugin participant (the trunk)
3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403)
4 Users can choose “regular” stack or trunk stack (UI in SIP demo page)
5 Trunk users present their SIP URI but don’t register (local mapping)
6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user)
7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog)
8 Events for WebRTC users delegated to user thread (not to block shared loop)
Sample sequence diagram
What’s next/missing? A lot!
• Peering at the moment only done at the UDP/TCP level
• May be enough in most use cases, but what if auth is needed?
• Will we need auth at SIP level? TLS level? Something else?
• To make things simple, only a single hardcoded trunk is supported
• We should allow multiple trunks to be created (and dynamically, via API)
• There’s no auth done on WebRTC users either, at the moment
• Users are free to use the existing trunk, if it exists
• Users are free to choose any SIP URI for local mapping
• Does it make sense to wait for user, if they’re not there when a call arrives?
• Shared SIP stack allows for it (per-user stack doesn’t)
• May be useful for scenarios associated with push notifications
What’s next/missing? A lot!
• Peering at the moment only done at the UDP/TCP level
• May be enough in most use cases, but what if auth is needed?
• Will we need auth at SIP level? TLS level? Something else?
• To make things simple, only a single hardcoded trunk is supported
• We should allow multiple trunks to be created (and dynamically, via API)
• There’s no auth done on WebRTC users either, at the moment
• Users are free to use the existing trunk, if it exists
• Users are free to choose any SIP URI for local mapping
• Does it make sense to wait for user, if they’re not there when a call arrives?
• Shared SIP stack allows for it (per-user stack doesn’t)
• May be useful for scenarios associated with push notifications
What’s next/missing? A lot!
• Peering at the moment only done at the UDP/TCP level
• May be enough in most use cases, but what if auth is needed?
• Will we need auth at SIP level? TLS level? Something else?
• To make things simple, only a single hardcoded trunk is supported
• We should allow multiple trunks to be created (and dynamically, via API)
• There’s no auth done on WebRTC users either, at the moment
• Users are free to use the existing trunk, if it exists
• Users are free to choose any SIP URI for local mapping
• Does it make sense to wait for user, if they’re not there when a call arrives?
• Shared SIP stack allows for it (per-user stack doesn’t)
• May be useful for scenarios associated with push notifications
What’s next/missing? A lot!
• Peering at the moment only done at the UDP/TCP level
• May be enough in most use cases, but what if auth is needed?
• Will we need auth at SIP level? TLS level? Something else?
• To make things simple, only a single hardcoded trunk is supported
• We should allow multiple trunks to be created (and dynamically, via API)
• There’s no auth done on WebRTC users either, at the moment
• Users are free to use the existing trunk, if it exists
• Users are free to choose any SIP URI for local mapping
• Does it make sense to wait for user, if they’re not there when a call arrives?
• Shared SIP stack allows for it (per-user stack doesn’t)
• May be useful for scenarios associated with push notifications
Thanks! Questions? Comments?
Contacts
• https://fosstodon.org/@lminiero
• https://twitter.com/elminiero
• https://twitter.com/meetecho
• https://www.meetecho.com/blog/
JanusCon is back, see you soon in Napoli!
April 29-30th
Napoli, Italy
https://januscon.it

More Related Content

Similar to SIP trunking in Janus @ Kamailio World 2024

Similar to SIP trunking in Janus @ Kamailio World 2024 (20)

The challenges of hybrid meetings @ CommCon 2023
The challenges of hybrid meetings @ CommCon 2023The challenges of hybrid meetings @ CommCon 2023
The challenges of hybrid meetings @ CommCon 2023
 
Janus Workshop @ ClueCon 2020
Janus Workshop @ ClueCon 2020Janus Workshop @ ClueCon 2020
Janus Workshop @ ClueCon 2020
 
Multistream in Janus @ CommCon 2019
Multistream in Janus @ CommCon 2019Multistream in Janus @ CommCon 2019
Multistream in Janus @ CommCon 2019
 
Fuzzing Janus @ IPTComm 2019
Fuzzing Janus @ IPTComm 2019Fuzzing Janus @ IPTComm 2019
Fuzzing Janus @ IPTComm 2019
 
Write a SocialTV app @ OpenSIPS 2021
Write a SocialTV app @ OpenSIPS 2021Write a SocialTV app @ OpenSIPS 2021
Write a SocialTV app @ OpenSIPS 2021
 
Janus @ RTC2017 Beijing
Janus @ RTC2017 BeijingJanus @ RTC2017 Beijing
Janus @ RTC2017 Beijing
 
Setting Up .Onion Addresses for your Enterprise, v3.5
Setting Up .Onion Addresses for your Enterprise, v3.5Setting Up .Onion Addresses for your Enterprise, v3.5
Setting Up .Onion Addresses for your Enterprise, v3.5
 
Janus/SIP @ OpenSIPS 2019
Janus/SIP @ OpenSIPS 2019Janus/SIP @ OpenSIPS 2019
Janus/SIP @ OpenSIPS 2019
 
Fuzzing RTC @ Kamailio World 2019
Fuzzing RTC @ Kamailio World 2019Fuzzing RTC @ Kamailio World 2019
Fuzzing RTC @ Kamailio World 2019
 
Janus/Asterisk @ Astricon 2017
Janus/Asterisk @ Astricon 2017Janus/Asterisk @ Astricon 2017
Janus/Asterisk @ Astricon 2017
 
SIP/WebRTC load testing @ KamailioWorld 2017
SIP/WebRTC load testing @ KamailioWorld 2017SIP/WebRTC load testing @ KamailioWorld 2017
SIP/WebRTC load testing @ KamailioWorld 2017
 
ProjectTox: Free as in freedom Skype replacement
ProjectTox: Free as in freedom Skype replacementProjectTox: Free as in freedom Skype replacement
ProjectTox: Free as in freedom Skype replacement
 
WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024
 
Janus/SIP @ OpenSIPS 2017
Janus/SIP @ OpenSIPS 2017Janus/SIP @ OpenSIPS 2017
Janus/SIP @ OpenSIPS 2017
 
NullMQ @ PDX
NullMQ @ PDXNullMQ @ PDX
NullMQ @ PDX
 
Fun with Linux Telephony
Fun with Linux TelephonyFun with Linux Telephony
Fun with Linux Telephony
 
But we're already open source! Why would I want to bring my code to Apache?
But we're already open source! Why would I want to bring my code to Apache?But we're already open source! Why would I want to bring my code to Apache?
But we're already open source! Why would I want to bring my code to Apache?
 
Introduction to FreeSWITCH
Introduction to FreeSWITCHIntroduction to FreeSWITCH
Introduction to FreeSWITCH
 
But We're Already Open Source! Why Would I Want To Bring My Code To Apache?
But We're Already Open Source! Why Would I Want To Bring My Code To Apache?But We're Already Open Source! Why Would I Want To Bring My Code To Apache?
But We're Already Open Source! Why Would I Want To Bring My Code To Apache?
 
What is Kafka & why is it Important? (UKOUG Tech17, Birmingham, UK - December...
What is Kafka & why is it Important? (UKOUG Tech17, Birmingham, UK - December...What is Kafka & why is it Important? (UKOUG Tech17, Birmingham, UK - December...
What is Kafka & why is it Important? (UKOUG Tech17, Birmingham, UK - December...
 

More from Lorenzo Miniero

More from Lorenzo Miniero (19)

Getting AV1/SVC to work in the Janus WebRTC Server
Getting AV1/SVC to work in the Janus WebRTC ServerGetting AV1/SVC to work in the Janus WebRTC Server
Getting AV1/SVC to work in the Janus WebRTC Server
 
BWE in Janus
BWE in JanusBWE in Janus
BWE in Janus
 
Real-Time Text and WebRTC @ Kamailio World 2023
Real-Time Text and WebRTC @ Kamailio World 2023Real-Time Text and WebRTC @ Kamailio World 2023
Real-Time Text and WebRTC @ Kamailio World 2023
 
Become a rockstar using FOSS!
Become a rockstar using FOSS!Become a rockstar using FOSS!
Become a rockstar using FOSS!
 
Janus SFU cascading @ IIT-RTC 2022
Janus SFU cascading @ IIT-RTC 2022Janus SFU cascading @ IIT-RTC 2022
Janus SFU cascading @ IIT-RTC 2022
 
JamRTC @ Wonder WebRTC unConference
JamRTC @ Wonder WebRTC unConferenceJamRTC @ Wonder WebRTC unConference
JamRTC @ Wonder WebRTC unConference
 
Scaling WebRTC deployments with multicast @ IETF 110 MBONED
Scaling WebRTC deployments with multicast @ IETF 110 MBONEDScaling WebRTC deployments with multicast @ IETF 110 MBONED
Scaling WebRTC deployments with multicast @ IETF 110 MBONED
 
Janus Workshop pt.2 @ ClueCon 2021
Janus Workshop pt.2 @ ClueCon 2021Janus Workshop pt.2 @ ClueCon 2021
Janus Workshop pt.2 @ ClueCon 2021
 
Janus + NDI @ ClueCon 2021
Janus + NDI @ ClueCon 2021Janus + NDI @ ClueCon 2021
Janus + NDI @ ClueCon 2021
 
Can WebRTC help musicians? @ FOSDEM 2021
Can WebRTC help musicians? @ FOSDEM 2021Can WebRTC help musicians? @ FOSDEM 2021
Can WebRTC help musicians? @ FOSDEM 2021
 
Virtual IETF meetings with WebRTC @ IETF 109 MOPS
Virtual IETF meetings with WebRTC @ IETF 109 MOPSVirtual IETF meetings with WebRTC @ IETF 109 MOPS
Virtual IETF meetings with WebRTC @ IETF 109 MOPS
 
Can SFUs and MCUs be friends @ IIT-RTC 2020
Can SFUs and MCUs be friends @ IIT-RTC 2020Can SFUs and MCUs be friends @ IIT-RTC 2020
Can SFUs and MCUs be friends @ IIT-RTC 2020
 
Insertable Streams and E2EE @ ClueCon2020
Insertable Streams and E2EE @ ClueCon2020Insertable Streams and E2EE @ ClueCon2020
Insertable Streams and E2EE @ ClueCon2020
 
Turning live events to virtual with Janus
Turning live events to virtual with JanusTurning live events to virtual with Janus
Turning live events to virtual with Janus
 
Janus RTP forwarders @ FOSDEM 2020
Janus RTP forwarders @ FOSDEM 2020Janus RTP forwarders @ FOSDEM 2020
Janus RTP forwarders @ FOSDEM 2020
 
Janus workshop @ RTC2019 Beijing
Janus workshop @ RTC2019 BeijingJanus workshop @ RTC2019 Beijing
Janus workshop @ RTC2019 Beijing
 
Simulcast/SVC @ IIT-RTC 2019
Simulcast/SVC @ IIT-RTC 2019Simulcast/SVC @ IIT-RTC 2019
Simulcast/SVC @ IIT-RTC 2019
 
Welcome to JanusCon! -- Past, Present and Future of Janus
Welcome to JanusCon! -- Past, Present and Future of JanusWelcome to JanusCon! -- Past, Present and Future of Janus
Welcome to JanusCon! -- Past, Present and Future of Janus
 
Janus @ ClueCon 2019
Janus @ ClueCon 2019Janus @ ClueCon 2019
Janus @ ClueCon 2019
 

Recently uploaded

Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
panagenda
 
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
FIDO Alliance
 
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc
 

Recently uploaded (20)

Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
 
Vector Search @ sw2con for slideshare.pptx
Vector Search @ sw2con for slideshare.pptxVector Search @ sw2con for slideshare.pptx
Vector Search @ sw2con for slideshare.pptx
 
The Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightThe Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and Insight
 
Event-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream ProcessingEvent-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream Processing
 
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
 
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
 
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
 
AI mind or machine power point presentation
AI mind or machine power point presentationAI mind or machine power point presentation
AI mind or machine power point presentation
 
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdfLinux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
Linux Foundation Edge _ Overview of FDO Software Components _ Randy at Intel.pdf
 
State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!
 
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
 
ERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage IntacctERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage Intacct
 
Intro in Product Management - Коротко про професію продакт менеджера
Intro in Product Management - Коротко про професію продакт менеджераIntro in Product Management - Коротко про професію продакт менеджера
Intro in Product Management - Коротко про професію продакт менеджера
 
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
 
2024 May Patch Tuesday
2024 May Patch Tuesday2024 May Patch Tuesday
2024 May Patch Tuesday
 
The Metaverse: Are We There Yet?
The  Metaverse:    Are   We  There  Yet?The  Metaverse:    Are   We  There  Yet?
The Metaverse: Are We There Yet?
 
Intro to Passkeys and the State of Passwordless.pptx
Intro to Passkeys and the State of Passwordless.pptxIntro to Passkeys and the State of Passwordless.pptx
Intro to Passkeys and the State of Passwordless.pptx
 
JavaScript Usage Statistics 2024 - The Ultimate Guide
JavaScript Usage Statistics 2024 - The Ultimate GuideJavaScript Usage Statistics 2024 - The Ultimate Guide
JavaScript Usage Statistics 2024 - The Ultimate Guide
 
Using IESVE for Room Loads Analysis - UK & Ireland
Using IESVE for Room Loads Analysis - UK & IrelandUsing IESVE for Room Loads Analysis - UK & Ireland
Using IESVE for Room Loads Analysis - UK & Ireland
 
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdfHow Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
 

SIP trunking in Janus @ Kamailio World 2024

  • 1. Am I Sober Or Am I Trunk? A Janus Story Lorenzo Miniero @lminiero@fosstodon.org Kamailio World April 19th 2024,
  • 2. Who am I? Lorenzo Miniero • Ph.D @ UniNA • Chairman @ Meetecho • Main author of Janus Contacts and info • lorenzo@meetecho.com • https://fosstodon.org/@lminiero • https://www.meetecho.com • https://lminiero.it
  • 3. Just 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
  • 4. A bit of context: Janus, WebRTC and SIP Janus General purpose, open source WebRTC server • https://github.com/meetecho/janus-gateway • Demos and documentation: https://janus.conf.meetecho.com • Community: https://janus.discourse.group/
  • 5. SIP plugin in Janus https://janus.conf.meetecho.com/docs/sip
  • 6. An endpoint of behalf of WebRTC users • Janus SIP plugin acts as a collection of SIP endpoints, not a server/trunk • SIP stack implemented with Sofia-SIP • WebRTC users only see the Janus API (JSON), no SIP • 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 dialogs (call, answer, hangup, message, etc.) • Allows SIP headers injection in many requests • Support for more advanced features too (e.g., hold, transfer, real-time text, etc.)
  • 7. An endpoint of behalf of WebRTC users • Janus SIP plugin acts as a collection of SIP endpoints, not a server/trunk • SIP stack implemented with Sofia-SIP • WebRTC users only see the Janus API (JSON), no SIP • 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 dialogs (call, answer, hangup, message, etc.) • Allows SIP headers injection in many requests • Support for more advanced features too (e.g., hold, transfer, real-time text, etc.)
  • 8. Works great with Kamailio!
  • 9. Remember this silly demo from last year?
  • 10. Different users = different SIP stacks
  • 11. What if we DO want trunking, though?
  • 12. What’s a trunk anyway? • A lot of buzzwords out there! • Tried googling “SIP trunk” • A gazillion of commercial fluff, very little technical details • Basically (don’t quote me on that!), the digital equivalent of old analogue lines • A group of phone lines implemented with SIP • A way to connect multiple channels to, e.g., a PBX • But isn’t that what SIP allows for already? • No hardware limitations as in PSTN • It’s over IP, we can have as many channels as we want
  • 13. What’s a trunk anyway? • A lot of buzzwords out there! • Tried googling “SIP trunk” • A gazillion of commercial fluff, very little technical details • Basically (don’t quote me on that!), the digital equivalent of old analogue lines • A group of phone lines implemented with SIP • A way to connect multiple channels to, e.g., a PBX • But isn’t that what SIP allows for already? • No hardware limitations as in PSTN • It’s over IP, we can have as many channels as we want
  • 14. What’s a trunk anyway? • A lot of buzzwords out there! • Tried googling “SIP trunk” • A gazillion of commercial fluff, very little technical details • Basically (don’t quote me on that!), the digital equivalent of old analogue lines • A group of phone lines implemented with SIP • A way to connect multiple channels to, e.g., a PBX • But isn’t that what SIP allows for already? • No hardware limitations as in PSTN • It’s over IP, we can have as many channels as we want
  • 15. What’s a trunk anyway? • More formally (maybe?), a way to connect private and public domains • e.g., a private PBX and the PSTN • More in general, interconnection between two SIP servers? • e.g., IP based peering (address:port) • Possibly with authentication (SIP based? TLS?) • That’s something Janus could benefit from, in some cases • Ensure all outgoing calls from WebRTC users go through a specific server • Ensure all incoming calls for WebRTC users come from a specific server • May help get rid of registrations, when unneeded (e.g., contact center)
  • 16. What’s a trunk anyway? • More formally (maybe?), a way to connect private and public domains • e.g., a private PBX and the PSTN • More in general, interconnection between two SIP servers? • e.g., IP based peering (address:port) • Possibly with authentication (SIP based? TLS?) • That’s something Janus could benefit from, in some cases • Ensure all outgoing calls from WebRTC users go through a specific server • Ensure all incoming calls for WebRTC users come from a specific server • May help get rid of registrations, when unneeded (e.g., contact center)
  • 17. What’s a trunk anyway? • More formally (maybe?), a way to connect private and public domains • e.g., a private PBX and the PSTN • More in general, interconnection between two SIP servers? • e.g., IP based peering (address:port) • Possibly with authentication (SIP based? TLS?) • That’s something Janus could benefit from, in some cases • Ensure all outgoing calls from WebRTC users go through a specific server • Ensure all incoming calls for WebRTC users come from a specific server • May help get rid of registrations, when unneeded (e.g., contact center)
  • 18. What’s a trunk anyway? • More formally (maybe?), a way to connect private and public domains • e.g., a private PBX and the PSTN • More in general, interconnection between two SIP servers? • e.g., IP based peering (address:port) • Possibly with authentication (SIP based? TLS?) • That’s something Janus could benefit from, in some cases • Ensure all outgoing calls from WebRTC users go through a specific server • Ensure all incoming calls for WebRTC users come from a specific server • May help get rid of registrations, when unneeded (e.g., contact center)
  • 19. What’s a trunk anyway? • More formally (maybe?), a way to connect private and public domains • e.g., a private PBX and the PSTN • More in general, interconnection between two SIP servers? • e.g., IP based peering (address:port) • Possibly with authentication (SIP based? TLS?) • That’s something Janus could benefit from, in some cases • Ensure all outgoing calls from WebRTC users go through a specific server • Ensure all incoming calls for WebRTC users come from a specific server • May help get rid of registrations, when unneeded (e.g., contact center)
  • 20. What’s a trunk anyway? • More formally (maybe?), a way to connect private and public domains • e.g., a private PBX and the PSTN • More in general, interconnection between two SIP servers? • e.g., IP based peering (address:port) • Possibly with authentication (SIP based? TLS?) • That’s something Janus could benefit from, in some cases • Ensure all outgoing calls from WebRTC users go through a specific server • Ensure all incoming calls for WebRTC users come from a specific server • May help get rid of registrations, when unneeded (e.g., contact center)
  • 21. How do we do that with Janus, though? • As we said, Janus is a collection of endpoints, not a SIP server • Setting an outbound proxy is easy (supported already) • No way to limit incoming traffic too, though (users have their own bound address) • In theory, a couple of potential approaches 1 Implement an internal proxy in Janus 2 Refactor the SIP plugin to allow a shared SIP stack • Both approaches have pros and cons • ... and headaches in terms of implementation details!
  • 22. How do we do that with Janus, though? • As we said, Janus is a collection of endpoints, not a SIP server • Setting an outbound proxy is easy (supported already) • No way to limit incoming traffic too, though (users have their own bound address) • In theory, a couple of potential approaches 1 Implement an internal proxy in Janus 2 Refactor the SIP plugin to allow a shared SIP stack • Both approaches have pros and cons • ... and headaches in terms of implementation details!
  • 23. How do we do that with Janus, though? • As we said, Janus is a collection of endpoints, not a SIP server • Setting an outbound proxy is easy (supported already) • No way to limit incoming traffic too, though (users have their own bound address) • In theory, a couple of potential approaches 1 Implement an internal proxy in Janus 2 Refactor the SIP plugin to allow a shared SIP stack • Both approaches have pros and cons • ... and headaches in terms of implementation details!
  • 24. How do we do that with Janus, though? • As we said, Janus is a collection of endpoints, not a SIP server • Setting an outbound proxy is easy (supported already) • No way to limit incoming traffic too, though (users have their own bound address) • In theory, a couple of potential approaches 1 Implement an internal proxy in Janus 2 Refactor the SIP plugin to allow a shared SIP stack • Both approaches have pros and cons • ... and headaches in terms of implementation details!
  • 25. How do we do that with Janus, though? • As we said, Janus is a collection of endpoints, not a SIP server • Setting an outbound proxy is easy (supported already) • No way to limit incoming traffic too, though (users have their own bound address) • In theory, a couple of potential approaches 1 Implement an internal proxy in Janus 2 Refactor the SIP plugin to allow a shared SIP stack • Both approaches have pros and cons • ... and headaches in terms of implementation details!
  • 26. Implementing an internal proxy in Janus • This was the first idea that came to mind, as in theory “simpler” • Proxy implementing the trunking part • Addressing calls based on SIP URI (which Janus knows even for unregistered users) • PRO: No need to touch the existing Janus SIP code • We can keep the “collection of endpoints” approach • Stack simply uses the local proxy as outbound proxy • Everything else remains the same • CON: But it isn’t really simple, at all! • Writing a proxy, even if internal, would be a huge undertaking!! • Besides, it would be a “silent”, hidden and unneeded hop
  • 27. Implementing an internal proxy in Janus • This was the first idea that came to mind, as in theory “simpler” • Proxy implementing the trunking part • Addressing calls based on SIP URI (which Janus knows even for unregistered users) • PRO: No need to touch the existing Janus SIP code • We can keep the “collection of endpoints” approach • Stack simply uses the local proxy as outbound proxy • Everything else remains the same • CON: But it isn’t really simple, at all! • Writing a proxy, even if internal, would be a huge undertaking!! • Besides, it would be a “silent”, hidden and unneeded hop
  • 28. Implementing an internal proxy in Janus • This was the first idea that came to mind, as in theory “simpler” • Proxy implementing the trunking part • Addressing calls based on SIP URI (which Janus knows even for unregistered users) • PRO: No need to touch the existing Janus SIP code • We can keep the “collection of endpoints” approach • Stack simply uses the local proxy as outbound proxy • Everything else remains the same • CON: But it isn’t really simple, at all! • Writing a proxy, even if internal, would be a huge undertaking!! • Besides, it would be a “silent”, hidden and unneeded hop
  • 29. Refactor the SIP plugin (shared SIP stack) • What if we instead allow different Janus users to re-use the same Sofia-SIP stack? • This SIP stack could implement the peering, and enforce an outbound proxy • Incoming dialogs could be processed in terms of who they’re for • Call is for User X −→ notify it to WebRTC User X • CON: Does requite changes to the SIP plugin code • Sofia event loop would not have 1-1 association with specific user • Users management, interactions and cleanup would need to be updated too • PRO: Would be much easier to implement than a full proxy, though • And most importantly, wouldn’t add an unneeded hop in the process
  • 30. Refactor the SIP plugin (shared SIP stack) • What if we instead allow different Janus users to re-use the same Sofia-SIP stack? • This SIP stack could implement the peering, and enforce an outbound proxy • Incoming dialogs could be processed in terms of who they’re for • Call is for User X −→ notify it to WebRTC User X • CON: Does requite changes to the SIP plugin code • Sofia event loop would not have 1-1 association with specific user • Users management, interactions and cleanup would need to be updated too • PRO: Would be much easier to implement than a full proxy, though • And most importantly, wouldn’t add an unneeded hop in the process
  • 31. Refactor the SIP plugin (shared SIP stack) • What if we instead allow different Janus users to re-use the same Sofia-SIP stack? • This SIP stack could implement the peering, and enforce an outbound proxy • Incoming dialogs could be processed in terms of who they’re for • Call is for User X −→ notify it to WebRTC User X • CON: Does requite changes to the SIP plugin code • Sofia event loop would not have 1-1 association with specific user • Users management, interactions and cleanup would need to be updated too • PRO: Would be much easier to implement than a full proxy, though • And most importantly, wouldn’t add an unneeded hop in the process
  • 32. A single stack to rule them all https://github.com/meetecho/janus-gateway/tree/sip-trunk
  • 33. A single stack to rule them all https://github.com/meetecho/janus-gateway/tree/sip-trunk
  • 34. Implementation details (and challenges) 1 Trunk has a dedicated structure (IP peering details) 2 Stack associated to a “fake” SIP plugin participant (the trunk) 3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403) 4 Users can choose “regular” stack or trunk stack (UI in SIP demo page) 5 Trunk users present their SIP URI but don’t register (local mapping) 6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user) 7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog) 8 Events for WebRTC users delegated to user thread (not to block shared loop)
  • 35. Implementation details (and challenges) 1 Trunk has a dedicated structure (IP peering details) 2 Stack associated to a “fake” SIP plugin participant (the trunk) 3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403) 4 Users can choose “regular” stack or trunk stack (UI in SIP demo page) 5 Trunk users present their SIP URI but don’t register (local mapping) 6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user) 7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog) 8 Events for WebRTC users delegated to user thread (not to block shared loop)
  • 36. Implementation details (and challenges) 1 Trunk has a dedicated structure (IP peering details) 2 Stack associated to a “fake” SIP plugin participant (the trunk) 3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403) 4 Users can choose “regular” stack or trunk stack (UI in SIP demo page) 5 Trunk users present their SIP URI but don’t register (local mapping) 6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user) 7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog) 8 Events for WebRTC users delegated to user thread (not to block shared loop)
  • 37. Implementation details (and challenges) 1 Trunk has a dedicated structure (IP peering details) 2 Stack associated to a “fake” SIP plugin participant (the trunk) 3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403) 4 Users can choose “regular” stack or trunk stack (UI in SIP demo page) 5 Trunk users present their SIP URI but don’t register (local mapping) 6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user) 7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog) 8 Events for WebRTC users delegated to user thread (not to block shared loop)
  • 38. Implementation details (and challenges) 1 Trunk has a dedicated structure (IP peering details) 2 Stack associated to a “fake” SIP plugin participant (the trunk) 3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403) 4 Users can choose “regular” stack or trunk stack (UI in SIP demo page) 5 Trunk users present their SIP URI but don’t register (local mapping) 6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user) 7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog) 8 Events for WebRTC users delegated to user thread (not to block shared loop)
  • 39. Implementation details (and challenges) 1 Trunk has a dedicated structure (IP peering details) 2 Stack associated to a “fake” SIP plugin participant (the trunk) 3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403) 4 Users can choose “regular” stack or trunk stack (UI in SIP demo page) 5 Trunk users present their SIP URI but don’t register (local mapping) 6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user) 7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog) 8 Events for WebRTC users delegated to user thread (not to block shared loop)
  • 40. Implementation details (and challenges) 1 Trunk has a dedicated structure (IP peering details) 2 Stack associated to a “fake” SIP plugin participant (the trunk) 3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403) 4 Users can choose “regular” stack or trunk stack (UI in SIP demo page) 5 Trunk users present their SIP URI but don’t register (local mapping) 6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user) 7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog) 8 Events for WebRTC users delegated to user thread (not to block shared loop)
  • 41. Implementation details (and challenges) 1 Trunk has a dedicated structure (IP peering details) 2 Stack associated to a “fake” SIP plugin participant (the trunk) 3 Peering enforced at the UDP/TCP level (message from unknown address −→ 403) 4 Users can choose “regular” stack or trunk stack (UI in SIP demo page) 5 Trunk users present their SIP URI but don’t register (local mapping) 6 Outgoing dialogs −→ trunk SIP stack is used (map dialog to user) 7 Incoming dialogs −→ trunk SIP loop finds user from headers (or existing dialog) 8 Events for WebRTC users delegated to user thread (not to block shared loop)
  • 43. What’s next/missing? A lot! • Peering at the moment only done at the UDP/TCP level • May be enough in most use cases, but what if auth is needed? • Will we need auth at SIP level? TLS level? Something else? • To make things simple, only a single hardcoded trunk is supported • We should allow multiple trunks to be created (and dynamically, via API) • There’s no auth done on WebRTC users either, at the moment • Users are free to use the existing trunk, if it exists • Users are free to choose any SIP URI for local mapping • Does it make sense to wait for user, if they’re not there when a call arrives? • Shared SIP stack allows for it (per-user stack doesn’t) • May be useful for scenarios associated with push notifications
  • 44. What’s next/missing? A lot! • Peering at the moment only done at the UDP/TCP level • May be enough in most use cases, but what if auth is needed? • Will we need auth at SIP level? TLS level? Something else? • To make things simple, only a single hardcoded trunk is supported • We should allow multiple trunks to be created (and dynamically, via API) • There’s no auth done on WebRTC users either, at the moment • Users are free to use the existing trunk, if it exists • Users are free to choose any SIP URI for local mapping • Does it make sense to wait for user, if they’re not there when a call arrives? • Shared SIP stack allows for it (per-user stack doesn’t) • May be useful for scenarios associated with push notifications
  • 45. What’s next/missing? A lot! • Peering at the moment only done at the UDP/TCP level • May be enough in most use cases, but what if auth is needed? • Will we need auth at SIP level? TLS level? Something else? • To make things simple, only a single hardcoded trunk is supported • We should allow multiple trunks to be created (and dynamically, via API) • There’s no auth done on WebRTC users either, at the moment • Users are free to use the existing trunk, if it exists • Users are free to choose any SIP URI for local mapping • Does it make sense to wait for user, if they’re not there when a call arrives? • Shared SIP stack allows for it (per-user stack doesn’t) • May be useful for scenarios associated with push notifications
  • 46. What’s next/missing? A lot! • Peering at the moment only done at the UDP/TCP level • May be enough in most use cases, but what if auth is needed? • Will we need auth at SIP level? TLS level? Something else? • To make things simple, only a single hardcoded trunk is supported • We should allow multiple trunks to be created (and dynamically, via API) • There’s no auth done on WebRTC users either, at the moment • Users are free to use the existing trunk, if it exists • Users are free to choose any SIP URI for local mapping • Does it make sense to wait for user, if they’re not there when a call arrives? • Shared SIP stack allows for it (per-user stack doesn’t) • May be useful for scenarios associated with push notifications
  • 47. Thanks! Questions? Comments? Contacts • https://fosstodon.org/@lminiero • https://twitter.com/elminiero • https://twitter.com/meetecho • https://www.meetecho.com/blog/
  • 48. JanusCon is back, see you soon in Napoli! April 29-30th Napoli, Italy https://januscon.it