LM
Uploaded byLorenzo Miniero
239 views

WebRTC and SIP not just audio and video @ OpenSIPS 2024

The document discusses the integration of WebRTC with SIP through the Janus gateway, highlighting the capabilities and challenges of handling audio, video, and non-media protocols like real-time text and instant messaging over data channels. It emphasizes the differences in protocol handling and the limitations of WebRTC when interfacing with SIP's broader ecosystem, detailed with practical examples and technical requirements. The content serves as a technical overview and a guide to bridging the functionalities of WebRTC and SIP for real-time communication applications.

Embed presentation

WebRTC-to-SIP and back It’s not all about audio and video! Lorenzo Miniero @lminiero@fosstodon.org OpenSIPS Summit May 15th 2024, Valencia
A chance to practice my broken Spanish!
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/interception in many requests • Support for more advanced features too (e.g., hold, transfer, 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/interception in many requests • Support for more advanced features too (e.g., hold, transfer, etc.)
Works great with OpenSIPS! Workshop on Janus and SIP (lesson/tutorial) at OpenSIPS 2020 https://www.youtube.com/watch?v=fv9KwrguR-4&t=3544s
Audio and video are “easy” • Both SIP and WebRTC use SDP and RTP/RTCP • WebRTC uses SDP/RTP/RTCP on “steroids” • Apart from this, just differences in encryption (WebRTC mandates DTLS-SRTP) • Media is basically encoded, packaged and sent the same way • As long as the same codec is used, they’re interoperable • When they aren’t, transcoding helps (but Janus won’t do it for you) • WebRTC has mandatory-to-implement codecs • Opus and G.711 for audio, VP8 and H.264 (baseline) for video • G.711 and H.264 should guarantee compliance with legacy equipment
Audio and video are “easy” • Both SIP and WebRTC use SDP and RTP/RTCP • WebRTC uses SDP/RTP/RTCP on “steroids” • Apart from this, just differences in encryption (WebRTC mandates DTLS-SRTP) • Media is basically encoded, packaged and sent the same way • As long as the same codec is used, they’re interoperable • When they aren’t, transcoding helps (but Janus won’t do it for you) • WebRTC has mandatory-to-implement codecs • Opus and G.711 for audio, VP8 and H.264 (baseline) for video • G.711 and H.264 should guarantee compliance with legacy equipment
Audio and video are “easy” • Both SIP and WebRTC use SDP and RTP/RTCP • WebRTC uses SDP/RTP/RTCP on “steroids” • Apart from this, just differences in encryption (WebRTC mandates DTLS-SRTP) • Media is basically encoded, packaged and sent the same way • As long as the same codec is used, they’re interoperable • When they aren’t, transcoding helps (but Janus won’t do it for you) • WebRTC has mandatory-to-implement codecs • Opus and G.711 for audio, VP8 and H.264 (baseline) for video • G.711 and H.264 should guarantee compliance with legacy equipment
SIP sometimes does more than that, though! • A whole ecosystem of other protocols that could be used • Real-Time Text (T.140 over RTP) • Message Session Relay Protocol (MSRP) • Binary Floor Control Protocol (BFCP) • Fax (T.38 over RTP) • ... • These protocols can’t simply be gateway-ed to WebRTC • WebRTC supports RTP, but only for audio/video, not generic data • Custom protocols are not supported at all • WebRTC-to-SIP gateways will in general strip them from the SDP • We can’t rely on a WebRTC browser to simply reject unsupported media • An unsupported m-line will cause an exception in setRemoteDescription
SIP sometimes does more than that, though! • A whole ecosystem of other protocols that could be used • Real-Time Text (T.140 over RTP) • Message Session Relay Protocol (MSRP) • Binary Floor Control Protocol (BFCP) • Fax (T.38 over RTP) • ... • These protocols can’t simply be gateway-ed to WebRTC • WebRTC supports RTP, but only for audio/video, not generic data • Custom protocols are not supported at all • WebRTC-to-SIP gateways will in general strip them from the SDP • We can’t rely on a WebRTC browser to simply reject unsupported media • An unsupported m-line will cause an exception in setRemoteDescription
SIP sometimes does more than that, though! • A whole ecosystem of other protocols that could be used • Real-Time Text (T.140 over RTP) • Message Session Relay Protocol (MSRP) • Binary Floor Control Protocol (BFCP) • Fax (T.38 over RTP) • ... • These protocols can’t simply be gateway-ed to WebRTC • WebRTC supports RTP, but only for audio/video, not generic data • Custom protocols are not supported at all • WebRTC-to-SIP gateways will in general strip them from the SDP • We can’t rely on a WebRTC browser to simply reject unsupported media • An unsupported m-line will cause an exception in setRemoteDescription
Data channels to the rescue!
Data channels to the rescue!
What are data channels? • Arbitrary real-time connection for pretty much anything • Bidirectional data between two WebRTC peers • Support for multiple channels of different kinds • Supports ordered/unordered and reliable/unreliable • Generic data sent via SCTP and encapsulated in DTLS • SCTP implements features, DTLS implements security • Negotiated as an application in the SDP • m=application 9 UDP/DTLS/SCTP webrtc-datachannel
What are data channels? • Arbitrary real-time connection for pretty much anything • Bidirectional data between two WebRTC peers • Support for multiple channels of different kinds • Supports ordered/unordered and reliable/unreliable • Generic data sent via SCTP and encapsulated in DTLS • SCTP implements features, DTLS implements security • Negotiated as an application in the SDP • m=application 9 UDP/DTLS/SCTP webrtc-datachannel
What are data channels? • Arbitrary real-time connection for pretty much anything • Bidirectional data between two WebRTC peers • Support for multiple channels of different kinds • Supports ordered/unordered and reliable/unreliable • Generic data sent via SCTP and encapsulated in DTLS • SCTP implements features, DTLS implements security • Negotiated as an application in the SDP • m=application 9 UDP/DTLS/SCTP webrtc-datachannel
That’s better, but still not enough! • Non audio/video protocols have their own technical requirements • RTT and T.38 will have custom RTP packetization rules • BFCP/MSRP/others will require custom UDP or TCP transport • All this will be reflected in the SDP negotiation • WebRTC only supports m=application + UDP/DTLS/SCTP • It’s the only non audio/video thing it can negotiate • A gateway will have more work to do than with RTP audio/video • Translate between SDP formats (e.g., custom protocol ↔ application) • Gateway the protocol itself (e.g., RTP/T.140 ↔ data channel)
That’s better, but still not enough! • Non audio/video protocols have their own technical requirements • RTT and T.38 will have custom RTP packetization rules • BFCP/MSRP/others will require custom UDP or TCP transport • All this will be reflected in the SDP negotiation • WebRTC only supports m=application + UDP/DTLS/SCTP • It’s the only non audio/video thing it can negotiate • A gateway will have more work to do than with RTP audio/video • Translate between SDP formats (e.g., custom protocol ↔ application) • Gateway the protocol itself (e.g., RTP/T.140 ↔ data channel)
That’s better, but still not enough! • Non audio/video protocols have their own technical requirements • RTT and T.38 will have custom RTP packetization rules • BFCP/MSRP/others will require custom UDP or TCP transport • All this will be reflected in the SDP negotiation • WebRTC only supports m=application + UDP/DTLS/SCTP • It’s the only non audio/video thing it can negotiate • A gateway will have more work to do than with RTP audio/video • Translate between SDP formats (e.g., custom protocol ↔ application) • Gateway the protocol itself (e.g., RTP/T.140 ↔ data channel)
A practical example: Real-Time Text (T.140) • Text transmitted instantly, as it is typed or created • ITU-T T.140 (Protocol for multimedia application text conversation) • Allows for real-time editing (e.g., backspace, rewriting) • T.140 messages transported over RTP • RFC 4103 (RTP Payload for Text Conversation) • Redundancy implemented via RED (RFC 2198) Specification to use T.140 over data channels • T.140 Real-Time Text Conversation over WebRTC Data Channels (RFC 8865) • https://www.rfc-editor.org/rfc/rfc8865.html
A practical example: Real-Time Text (T.140) • Text transmitted instantly, as it is typed or created • ITU-T T.140 (Protocol for multimedia application text conversation) • Allows for real-time editing (e.g., backspace, rewriting) • T.140 messages transported over RTP • RFC 4103 (RTP Payload for Text Conversation) • Redundancy implemented via RED (RFC 2198) Specification to use T.140 over data channels • T.140 Real-Time Text Conversation over WebRTC Data Channels (RFC 8865) • https://www.rfc-editor.org/rfc/rfc8865.html
A practical example: Real-Time Text (T.140) • Text transmitted instantly, as it is typed or created • ITU-T T.140 (Protocol for multimedia application text conversation) • Allows for real-time editing (e.g., backspace, rewriting) • T.140 messages transported over RTP • RFC 4103 (RTP Payload for Text Conversation) • Redundancy implemented via RED (RFC 2198) Specification to use T.140 over data channels • T.140 Real-Time Text Conversation over WebRTC Data Channels (RFC 8865) • https://www.rfc-editor.org/rfc/rfc8865.html
SIP plugin in Janus normally...
SIP plugin in Janus + RTT https://github.com/meetecho/janus-gateway/pull/3231
Example: SDP offer from SIP/RTT endpoint v=0 o=Lorenzo_Miniero 1 1 IN IP4 192.168.1.74 s=Omnitor_SDP_v1.1 c=IN IP4 192.168.1.74 t=0 0 m=text 1024 RTP/AVP 99 98 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98 a=rtpmap:98 t140/1000
Example: SDP offer to WebRTC endpoint v=0 o=Lorenzo_Miniero 1 1 IN IP4 192.168.1.74 s=Omnitor_SDP_v1.1 t=0 0 a=group:BUNDLE data a=msid-semantic: WMS janus m=application 9 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.168.1.74 a=sendrecv a=sctp-port:5000 a=mid:0 [.. ICE/DTLS details follow ..]
Testing: TIPcon1 (SIP/RTT) https://www.meetecho.com/blog/realtime-text-sip-and-webrtc/
Testing: Janus SIP demo (WebRTC) https://www.meetecho.com/blog/realtime-text-sip-and-webrtc/
A more complex example: MSRP • Instant Messaging protocol negotiated in SIP/SDP • RFC 4975 (Message Session Relay Protocol) • Requires a reliable transport (e.g., TCP) • Used m=message m-line type for negotiation • Protocol must be TCP/MSRP or TCP/TLS/MSRP • path attribute defines endpoints Specification to use MSRP over data channels • Message Session Relay Protocol (MSRP) over Data Channels (RFC 8873) • https://www.rfc-editor.org/rfc/rfc8873.html
A more complex example: MSRP • Instant Messaging protocol negotiated in SIP/SDP • RFC 4975 (Message Session Relay Protocol) • Requires a reliable transport (e.g., TCP) • Used m=message m-line type for negotiation • Protocol must be TCP/MSRP or TCP/TLS/MSRP • path attribute defines endpoints Specification to use MSRP over data channels • Message Session Relay Protocol (MSRP) over Data Channels (RFC 8873) • https://www.rfc-editor.org/rfc/rfc8873.html
A more complex example: MSRP • Instant Messaging protocol negotiated in SIP/SDP • RFC 4975 (Message Session Relay Protocol) • Requires a reliable transport (e.g., TCP) • Used m=message m-line type for negotiation • Protocol must be TCP/MSRP or TCP/TLS/MSRP • path attribute defines endpoints Specification to use MSRP over data channels • Message Session Relay Protocol (MSRP) over Data Channels (RFC 8873) • https://www.rfc-editor.org/rfc/rfc8873.html
Much more complex to handle than RTT • T.140 still uses RTP (and UDP) • Easier to integrate in existing Janus SIP plugin bridging • Complexity mostly in SDP translation (and maybe RED) • MSRP requires a reliable transport protocol • With TCP, who connects to who? • Integrating TCP with UDP poll loop can be tricky (head-of-line blocking) • On the WebRTC side, we need to be able to provide MSRP path • It won’t be in the SDP (attribute stripped) and dcsa unsupported by browsers • Needs out of band (Janus SIP plugin API?) mechanism for that
Much more complex to handle than RTT • T.140 still uses RTP (and UDP) • Easier to integrate in existing Janus SIP plugin bridging • Complexity mostly in SDP translation (and maybe RED) • MSRP requires a reliable transport protocol • With TCP, who connects to who? • Integrating TCP with UDP poll loop can be tricky (head-of-line blocking) • On the WebRTC side, we need to be able to provide MSRP path • It won’t be in the SDP (attribute stripped) and dcsa unsupported by browsers • Needs out of band (Janus SIP plugin API?) mechanism for that
Much more complex to handle than RTT • T.140 still uses RTP (and UDP) • Easier to integrate in existing Janus SIP plugin bridging • Complexity mostly in SDP translation (and maybe RED) • MSRP requires a reliable transport protocol • With TCP, who connects to who? • Integrating TCP with UDP poll loop can be tricky (head-of-line blocking) • On the WebRTC side, we need to be able to provide MSRP path • It won’t be in the SDP (attribute stripped) and dcsa unsupported by browsers • Needs out of band (Janus SIP plugin API?) mechanism for that
SIP plugin in Janus + MSRP https://github.com/meetecho/janus-gateway/tree/sip-msrp
Example: SDP offer from Blink (SIP/MSRP) v=0 o=- 3922178296 3922178296 IN IP4 192.168.1.74 s=Blink 5.5.1 (Linux) t=0 0 m=message 2855 TCP/MSRP * c=IN IP4 192.168.1.74 a=path:msrp://192.168.1.74:2855/59a83c96684d4fc5fa41;tcp a=accept-types:message/cpim text/* image/* application/im-iscomposing+xml a=accept-wrapped-types:text/* image/* application/im-iscomposing+xml a=setup:active
Example: SDP offer to WebRTC endpoint v=0 o=- 3922178296 3922178296 IN IP4 192.168.1.74 s=Blink 5.5.1 (Linux) t=0 0 a=group:BUNDLE 0 a=extmap-allow-mixed a=msid-semantic: WMS * m=application 9 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.168.1.74 a=sendrecv a=sctp-port:5000 [.. ICE/DTLS details follow ..]
Testing: Janus SIP demo (WebRTC)
What’s next? • Both RTT and MSRP “work” in Janus, but there’s a lot to do! • RTT is in a better shape, but needs testing with actual endpoints • MSRP in a more embrional stage, needs a lot of love • Multiple protocols in same PeerConnection not supported yet either • Data channels allow for that (single m-line, multiple labels) • We need better mapping when dealing with SDP translation • Maybe add support for other protocols? • Not sure what’s really used and needed, out there • Is this effort really worth it, though? • Probably yes for RTT (Emergency Services mandate it) • Other protocols may have better “solutions” already
What’s next? • Both RTT and MSRP “work” in Janus, but there’s a lot to do! • RTT is in a better shape, but needs testing with actual endpoints • MSRP in a more embrional stage, needs a lot of love • Multiple protocols in same PeerConnection not supported yet either • Data channels allow for that (single m-line, multiple labels) • We need better mapping when dealing with SDP translation • Maybe add support for other protocols? • Not sure what’s really used and needed, out there • Is this effort really worth it, though? • Probably yes for RTT (Emergency Services mandate it) • Other protocols may have better “solutions” already
What’s next? • Both RTT and MSRP “work” in Janus, but there’s a lot to do! • RTT is in a better shape, but needs testing with actual endpoints • MSRP in a more embrional stage, needs a lot of love • Multiple protocols in same PeerConnection not supported yet either • Data channels allow for that (single m-line, multiple labels) • We need better mapping when dealing with SDP translation • Maybe add support for other protocols? • Not sure what’s really used and needed, out there • Is this effort really worth it, though? • Probably yes for RTT (Emergency Services mandate it) • Other protocols may have better “solutions” already
What’s next? • Both RTT and MSRP “work” in Janus, but there’s a lot to do! • RTT is in a better shape, but needs testing with actual endpoints • MSRP in a more embrional stage, needs a lot of love • Multiple protocols in same PeerConnection not supported yet either • Data channels allow for that (single m-line, multiple labels) • We need better mapping when dealing with SDP translation • Maybe add support for other protocols? • Not sure what’s really used and needed, out there • Is this effort really worth it, though? • Probably yes for RTT (Emergency Services mandate it) • Other protocols may have better “solutions” already
Thanks! Questions? Comments? Contacts • https://fosstodon.org/@lminiero • https://twitter.com/elminiero • https://twitter.com/meetecho • https://www.meetecho.com/blog/

More Related Content

PDF
Microservices Architecture
byIzzet Mustafaiev
 
PPTX
API Management Within a Microservices Architecture
byNadeesha Gamage
 
PPTX
IBM Cloud Integration Platform Introduction - Integration Tech Conference
byRobert Nicholson
 
PDF
Microservices Design Patterns
byHaim Michael
 
PPTX
Microservicios net arquitectura para aplicaciones net contenerizadas - net ...
byGermán Küber
 
PDF
Enterprise java unit-3_chapter-1-jsp
bysandeep54552
 
PPTX
Architecture for the API-enterprise
byApigee | Google Cloud
 
PPTX
Springboot Microservices
byNexThoughts Technologies
 
Microservices Architecture
byIzzet Mustafaiev
 
API Management Within a Microservices Architecture
byNadeesha Gamage
 
IBM Cloud Integration Platform Introduction - Integration Tech Conference
byRobert Nicholson
 
Microservices Design Patterns
byHaim Michael
 
Microservicios net arquitectura para aplicaciones net contenerizadas - net ...
byGermán Küber
 
Enterprise java unit-3_chapter-1-jsp
bysandeep54552
 
Architecture for the API-enterprise
byApigee | Google Cloud
 
Springboot Microservices
byNexThoughts Technologies
 

What's hot

PDF
BPMN 2.0 Einfühung
byIOZ AG
 
PPTX
SAP_S4HANA.pptx
bysreekanth976901
 
PPTX
Cutover SAP All Presentation 202413.pptx
byadeelshoukat56
 
PDF
Microsoft Power Automate Questions and Answers
bySFSupport247
 
PDF
Workshop: An Introduction to API Automation with Javascript
byApplitools
 
PDF
The Architecture of an API Platform
byJohannes Ridderstedt
 
PDF
Evolution of API-driven architectures
bySven Bernhardt
 
PPTX
Raptor tool
byAbiramiTabiit
 
PPTX
sap hana|sap hana database| Introduction to sap hana
byJames L. Lee
 
PPTX
Machine Learning Orchestration with Airflow
byAnant Corporation
 
PDF
Bitrise - continuous happiness as a service
byKarol Wrótniak
 
PDF
Technical And Non Technical Sessions Proposal Powerpoint Presentation Slides
bySlideTeam
 
PDF
Deployment Methodology
byDavid Messineo
 
PPTX
Api gateway in microservices
byKunal Hire
 
PPTX
The Power of SAP and Ariba Solution Integration
bySAP Ariba
 
PPTX
Caching
byNascenia IT
 
PDF
tour management system
byKhwaja Yunus Ali Medical University
 
PPTX
GFOA Chart of Accounts
byShyamal Jajodia
 
DOC
nani testing resume
bynagendra kumar
 
DOCX
Abhijeet resume
bymailabhijeet
 
BPMN 2.0 Einfühung
byIOZ AG
 
SAP_S4HANA.pptx
bysreekanth976901
 
Cutover SAP All Presentation 202413.pptx
byadeelshoukat56
 
Microsoft Power Automate Questions and Answers
bySFSupport247
 
Workshop: An Introduction to API Automation with Javascript
byApplitools
 
The Architecture of an API Platform
byJohannes Ridderstedt
 
Evolution of API-driven architectures
bySven Bernhardt
 
Raptor tool
byAbiramiTabiit
 
sap hana|sap hana database| Introduction to sap hana
byJames L. Lee
 
Machine Learning Orchestration with Airflow
byAnant Corporation
 
Bitrise - continuous happiness as a service
byKarol Wrótniak
 
Technical And Non Technical Sessions Proposal Powerpoint Presentation Slides
bySlideTeam
 
Deployment Methodology
byDavid Messineo
 
Api gateway in microservices
byKunal Hire
 
The Power of SAP and Ariba Solution Integration
bySAP Ariba
 
Caching
byNascenia IT
 
tour management system
byKhwaja Yunus Ali Medical University
 
GFOA Chart of Accounts
byShyamal Jajodia
 
nani testing resume
bynagendra kumar
 
Abhijeet resume
bymailabhijeet
 

Similar to WebRTC and SIP not just audio and video @ OpenSIPS 2024

PDF
Janus/SIP @ OpenSIPS 2019
byLorenzo Miniero
 
PPTX
WebRTC overview
byRouyun Pan
 
PDF
Janus RTP forwarders @ FOSDEM 2020
byLorenzo Miniero
 
PDF
Janus/SIP @ OpenSIPS 2017
byLorenzo Miniero
 
PDF
Webrtc overview
byOlle E Johansson
 
PDF
Multistream in SIP and NoSIP @ OpenSIPS Summit 2025
byLorenzo Miniero
 
PDF
WebRTC for Telco: Informa's WebRTC Global Summit Preconference
byTsahi Levent-levi
 
PDF
WebRTC Overview by Dan Burnett
byMojo Lingo
 
PDF
WebRTC Summit November 2013 - WebRTC Interoperability (and why it is important)
byCrocodile WebRTC SDK and Cloud Signalling Network
 
PDF
WebRTC and VoIP: bridging the gap (Kamailio world conference 2013)
byVictor Pascual Ávila
 
PDF
WebRTC standards update - November 2014
byVictor Pascual Ávila
 
PDF
Workshop oracle
byDouglas Tait
 
PDF
WebRTC Standards Update (October 2014)
byVictor Pascual Ávila
 
PDF
WebRTC Workshop - What is (and isn't WebRTC)
byOracle
 
PDF
Webrtc - rich communication - quobis - victor pascual
byAlan Quayle
 
PDF
D1-3-Signaling
byOleg Levy
 
PDF
Asterisk World (January 2014) - Taking Enterprise Telephony into the Web World
byCrocodile WebRTC SDK and Cloud Signalling Network
 
PPTX
VozDigital DevFest 31/10/14
byjavier_fernandez_seco
 
PDF
WebRTC standards update (13 Nov 2013)
byVictor Pascual Ávila
 
PDF
An hour with WebRTC FIC UDC
byQuobis
 
Janus/SIP @ OpenSIPS 2019
byLorenzo Miniero
 
WebRTC overview
byRouyun Pan
 
Janus RTP forwarders @ FOSDEM 2020
byLorenzo Miniero
 
Janus/SIP @ OpenSIPS 2017
byLorenzo Miniero
 
Webrtc overview
byOlle E Johansson
 
Multistream in SIP and NoSIP @ OpenSIPS Summit 2025
byLorenzo Miniero
 
WebRTC for Telco: Informa's WebRTC Global Summit Preconference
byTsahi Levent-levi
 
WebRTC Overview by Dan Burnett
byMojo Lingo
 
WebRTC Summit November 2013 - WebRTC Interoperability (and why it is important)
byCrocodile WebRTC SDK and Cloud Signalling Network
 
WebRTC and VoIP: bridging the gap (Kamailio world conference 2013)
byVictor Pascual Ávila
 
WebRTC standards update - November 2014
byVictor Pascual Ávila
 
Workshop oracle
byDouglas Tait
 
WebRTC Standards Update (October 2014)
byVictor Pascual Ávila
 
WebRTC Workshop - What is (and isn't WebRTC)
byOracle
 
Webrtc - rich communication - quobis - victor pascual
byAlan Quayle
 
D1-3-Signaling
byOleg Levy
 
Asterisk World (January 2014) - Taking Enterprise Telephony into the Web World
byCrocodile WebRTC SDK and Cloud Signalling Network
 
VozDigital DevFest 31/10/14
byjavier_fernandez_seco
 
WebRTC standards update (13 Nov 2013)
byVictor Pascual Ávila
 
An hour with WebRTC FIC UDC
byQuobis
 

More from Lorenzo Miniero

PDF
Janus + Audio @ Open Source World
byLorenzo Miniero
 
PDF
WHIP WebRTC Broadcasting @ FOSDEM 2022
byLorenzo Miniero
 
PDF
Real-Time Text and WebRTC @ Kamailio World 2023
byLorenzo Miniero
 
PDF
BWE in Janus
byLorenzo Miniero
 
PDF
SIP trunking in Janus @ Kamailio World 2024
byLorenzo Miniero
 
PDF
WebRTC, RED and Janus @ ClueCon21
byLorenzo Miniero
 
PDF
The challenges of hybrid meetings @ CommCon 2023
byLorenzo Miniero
 
PDF
SIP transfer with Janus/WebRTC @ OpenSIPS 2022
byLorenzo Miniero
 
PDF
WebRTC Broadcasting @ TADSummit 2023
byLorenzo Miniero
 
PDF
RTP Over QUIC: An Interesting Opportunity Or Wasted Time?
byLorenzo Miniero
 
PDF
Janus Workshop pt.2 @ ClueCon 2021
byLorenzo Miniero
 
PDF
WHIP and Janus @ IIT-RTC 2021
byLorenzo Miniero
 
PDF
Scaling WebRTC deployments with multicast @ IETF 110 MBONED
byLorenzo Miniero
 
PDF
Janus + NDI @ ClueCon 2021
byLorenzo Miniero
 
PDF
Getting AV1/SVC to work in the Janus WebRTC Server
byLorenzo Miniero
 
PDF
Janus SFU cascading @ IIT-RTC 2022
byLorenzo Miniero
 
PDF
WebRTC and QUIC: how hard can it be? @ RTC.ON 2024
byLorenzo Miniero
 
PDF
JamRTC @ Wonder WebRTC unConference
byLorenzo Miniero
 
PDF
Write a SocialTV app @ OpenSIPS 2021
byLorenzo Miniero
 
PDF
Become a rockstar using FOSS!
byLorenzo Miniero
 
Janus + Audio @ Open Source World
byLorenzo Miniero
 
WHIP WebRTC Broadcasting @ FOSDEM 2022
byLorenzo Miniero
 
Real-Time Text and WebRTC @ Kamailio World 2023
byLorenzo Miniero
 
BWE in Janus
byLorenzo Miniero
 
SIP trunking in Janus @ Kamailio World 2024
byLorenzo Miniero
 
WebRTC, RED and Janus @ ClueCon21
byLorenzo Miniero
 
The challenges of hybrid meetings @ CommCon 2023
byLorenzo Miniero
 
SIP transfer with Janus/WebRTC @ OpenSIPS 2022
byLorenzo Miniero
 
WebRTC Broadcasting @ TADSummit 2023
byLorenzo Miniero
 
RTP Over QUIC: An Interesting Opportunity Or Wasted Time?
byLorenzo Miniero
 
Janus Workshop pt.2 @ ClueCon 2021
byLorenzo Miniero
 
WHIP and Janus @ IIT-RTC 2021
byLorenzo Miniero
 
Scaling WebRTC deployments with multicast @ IETF 110 MBONED
byLorenzo Miniero
 
Janus + NDI @ ClueCon 2021
byLorenzo Miniero
 
Getting AV1/SVC to work in the Janus WebRTC Server
byLorenzo Miniero
 
Janus SFU cascading @ IIT-RTC 2022
byLorenzo Miniero
 
WebRTC and QUIC: how hard can it be? @ RTC.ON 2024
byLorenzo Miniero
 
JamRTC @ Wonder WebRTC unConference
byLorenzo Miniero
 
Write a SocialTV app @ OpenSIPS 2021
byLorenzo Miniero
 
Become a rockstar using FOSS!
byLorenzo Miniero
 

Recently uploaded

PDF
Vibe Coding vs. Spec-Driven Development [Free Meetup]
byHaim Michael
 
PDF
Generative AI in UiPath: Mastering the Generative Extractor for Intelligent D...
byDianaGray10
 
PDF
The year in review - MarvelClient in 2025
bypanagenda
 
PDF
Session 1 - Solving Semi-Structured Documents with Document Understanding
byDianaGray10
 
PDF
Igniting the Future: Copilot trends, agentic transformation and product roadm...
byUni Systems S.M.S.A.
 
DOCX
Introduction to the World of Computers (Hardware & Software)
byALIABBAS ABASOV
 
PDF
Unlocking the Power of Salesforce Architecture: Frameworks for Effective Solu...
byvarsha30tiwari
 
PDF
TrustArc Webinar - Looking Ahead: The 2026 Privacy Landscape
byTrustArc
 
PDF
Usage Control for Process Discovery through a Trusted Execution Environment
byValerioGoretti
 
PDF
DIGITAL FORENSICS - Notes for Everything.pdf
bypankajkumavatbeit
 
PDF
AI and Computer Architecture: 200 Years Together
byDmitry Zinoviev
 
PDF
How Mobile Apps Are Shaping the Future of Digital Innovation
byWilliam Taylor
 
PPTX
Basics of Identity Access Management In mordern Infrastructure
byPrinceXavier18
 
PPTX
Ethics in AI - Artificial Intelligence Fundamentals.pptx
byemenyiblessing
 
PPTX
The Landscape of Computer Software Development Companies
byYash Singh
 
PDF
TrustArc Webinar - Assessing AI Risk with Confidence
byTrustArc
 
PDF
The Ultimate Guide to Problem Management Dashboards for IT Teams.pdf
byomnex systems
 
PDF
eResource Scheduler Enterprise Resource Management and Scheduling Software.pdf
byeResource Scheduler
 
PDF
TPPmark2025 Kenta Inoue's answer 12/04/2025
byKenta Inoue
 
PDF
8 LLM Surveys https://tinyurl.com/bdz8e6fp
byBob Marcus
 
Vibe Coding vs. Spec-Driven Development [Free Meetup]
byHaim Michael
 
Generative AI in UiPath: Mastering the Generative Extractor for Intelligent D...
byDianaGray10
 
The year in review - MarvelClient in 2025
bypanagenda
 
Session 1 - Solving Semi-Structured Documents with Document Understanding
byDianaGray10
 
Igniting the Future: Copilot trends, agentic transformation and product roadm...
byUni Systems S.M.S.A.
 
Introduction to the World of Computers (Hardware & Software)
byALIABBAS ABASOV
 
Unlocking the Power of Salesforce Architecture: Frameworks for Effective Solu...
byvarsha30tiwari
 
TrustArc Webinar - Looking Ahead: The 2026 Privacy Landscape
byTrustArc
 
Usage Control for Process Discovery through a Trusted Execution Environment
byValerioGoretti
 
DIGITAL FORENSICS - Notes for Everything.pdf
bypankajkumavatbeit
 
AI and Computer Architecture: 200 Years Together
byDmitry Zinoviev
 
How Mobile Apps Are Shaping the Future of Digital Innovation
byWilliam Taylor
 
Basics of Identity Access Management In mordern Infrastructure
byPrinceXavier18
 
Ethics in AI - Artificial Intelligence Fundamentals.pptx
byemenyiblessing
 
The Landscape of Computer Software Development Companies
byYash Singh
 
TrustArc Webinar - Assessing AI Risk with Confidence
byTrustArc
 
The Ultimate Guide to Problem Management Dashboards for IT Teams.pdf
byomnex systems
 
eResource Scheduler Enterprise Resource Management and Scheduling Software.pdf
byeResource Scheduler
 
TPPmark2025 Kenta Inoue's answer 12/04/2025
byKenta Inoue
 
8 LLM Surveys https://tinyurl.com/bdz8e6fp
byBob Marcus
 

WebRTC and SIP not just audio and video @ OpenSIPS 2024

  • 1.
    WebRTC-to-SIP and back It’snot all about audio and video! Lorenzo Miniero @lminiero@fosstodon.org OpenSIPS Summit May 15th 2024, Valencia
  • 2.
    A chance topractice my broken Spanish!
  • 3.
    Who am I? LorenzoMiniero • 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
  • 4.
    Just a fewwords 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
  • 5.
    A bit ofcontext: 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/
  • 6.
    SIP plugin inJanus https://janus.conf.meetecho.com/docs/sip
  • 7.
    An endpoint ofbehalf 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/interception in many requests • Support for more advanced features too (e.g., hold, transfer, etc.)
  • 8.
    An endpoint ofbehalf 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/interception in many requests • Support for more advanced features too (e.g., hold, transfer, etc.)
  • 9.
    Works great withOpenSIPS! Workshop on Janus and SIP (lesson/tutorial) at OpenSIPS 2020 https://www.youtube.com/watch?v=fv9KwrguR-4&t=3544s
  • 10.
    Audio and videoare “easy” • Both SIP and WebRTC use SDP and RTP/RTCP • WebRTC uses SDP/RTP/RTCP on “steroids” • Apart from this, just differences in encryption (WebRTC mandates DTLS-SRTP) • Media is basically encoded, packaged and sent the same way • As long as the same codec is used, they’re interoperable • When they aren’t, transcoding helps (but Janus won’t do it for you) • WebRTC has mandatory-to-implement codecs • Opus and G.711 for audio, VP8 and H.264 (baseline) for video • G.711 and H.264 should guarantee compliance with legacy equipment
  • 11.
    Audio and videoare “easy” • Both SIP and WebRTC use SDP and RTP/RTCP • WebRTC uses SDP/RTP/RTCP on “steroids” • Apart from this, just differences in encryption (WebRTC mandates DTLS-SRTP) • Media is basically encoded, packaged and sent the same way • As long as the same codec is used, they’re interoperable • When they aren’t, transcoding helps (but Janus won’t do it for you) • WebRTC has mandatory-to-implement codecs • Opus and G.711 for audio, VP8 and H.264 (baseline) for video • G.711 and H.264 should guarantee compliance with legacy equipment
  • 12.
    Audio and videoare “easy” • Both SIP and WebRTC use SDP and RTP/RTCP • WebRTC uses SDP/RTP/RTCP on “steroids” • Apart from this, just differences in encryption (WebRTC mandates DTLS-SRTP) • Media is basically encoded, packaged and sent the same way • As long as the same codec is used, they’re interoperable • When they aren’t, transcoding helps (but Janus won’t do it for you) • WebRTC has mandatory-to-implement codecs • Opus and G.711 for audio, VP8 and H.264 (baseline) for video • G.711 and H.264 should guarantee compliance with legacy equipment
  • 13.
    SIP sometimes doesmore than that, though! • A whole ecosystem of other protocols that could be used • Real-Time Text (T.140 over RTP) • Message Session Relay Protocol (MSRP) • Binary Floor Control Protocol (BFCP) • Fax (T.38 over RTP) • ... • These protocols can’t simply be gateway-ed to WebRTC • WebRTC supports RTP, but only for audio/video, not generic data • Custom protocols are not supported at all • WebRTC-to-SIP gateways will in general strip them from the SDP • We can’t rely on a WebRTC browser to simply reject unsupported media • An unsupported m-line will cause an exception in setRemoteDescription
  • 14.
    SIP sometimes doesmore than that, though! • A whole ecosystem of other protocols that could be used • Real-Time Text (T.140 over RTP) • Message Session Relay Protocol (MSRP) • Binary Floor Control Protocol (BFCP) • Fax (T.38 over RTP) • ... • These protocols can’t simply be gateway-ed to WebRTC • WebRTC supports RTP, but only for audio/video, not generic data • Custom protocols are not supported at all • WebRTC-to-SIP gateways will in general strip them from the SDP • We can’t rely on a WebRTC browser to simply reject unsupported media • An unsupported m-line will cause an exception in setRemoteDescription
  • 15.
    SIP sometimes doesmore than that, though! • A whole ecosystem of other protocols that could be used • Real-Time Text (T.140 over RTP) • Message Session Relay Protocol (MSRP) • Binary Floor Control Protocol (BFCP) • Fax (T.38 over RTP) • ... • These protocols can’t simply be gateway-ed to WebRTC • WebRTC supports RTP, but only for audio/video, not generic data • Custom protocols are not supported at all • WebRTC-to-SIP gateways will in general strip them from the SDP • We can’t rely on a WebRTC browser to simply reject unsupported media • An unsupported m-line will cause an exception in setRemoteDescription
  • 16.
    Data channels tothe rescue!
  • 17.
    Data channels tothe rescue!
  • 18.
    What are datachannels? • Arbitrary real-time connection for pretty much anything • Bidirectional data between two WebRTC peers • Support for multiple channels of different kinds • Supports ordered/unordered and reliable/unreliable • Generic data sent via SCTP and encapsulated in DTLS • SCTP implements features, DTLS implements security • Negotiated as an application in the SDP • m=application 9 UDP/DTLS/SCTP webrtc-datachannel
  • 19.
    What are datachannels? • Arbitrary real-time connection for pretty much anything • Bidirectional data between two WebRTC peers • Support for multiple channels of different kinds • Supports ordered/unordered and reliable/unreliable • Generic data sent via SCTP and encapsulated in DTLS • SCTP implements features, DTLS implements security • Negotiated as an application in the SDP • m=application 9 UDP/DTLS/SCTP webrtc-datachannel
  • 20.
    What are datachannels? • Arbitrary real-time connection for pretty much anything • Bidirectional data between two WebRTC peers • Support for multiple channels of different kinds • Supports ordered/unordered and reliable/unreliable • Generic data sent via SCTP and encapsulated in DTLS • SCTP implements features, DTLS implements security • Negotiated as an application in the SDP • m=application 9 UDP/DTLS/SCTP webrtc-datachannel
  • 21.
    That’s better, butstill not enough! • Non audio/video protocols have their own technical requirements • RTT and T.38 will have custom RTP packetization rules • BFCP/MSRP/others will require custom UDP or TCP transport • All this will be reflected in the SDP negotiation • WebRTC only supports m=application + UDP/DTLS/SCTP • It’s the only non audio/video thing it can negotiate • A gateway will have more work to do than with RTP audio/video • Translate between SDP formats (e.g., custom protocol ↔ application) • Gateway the protocol itself (e.g., RTP/T.140 ↔ data channel)
  • 22.
    That’s better, butstill not enough! • Non audio/video protocols have their own technical requirements • RTT and T.38 will have custom RTP packetization rules • BFCP/MSRP/others will require custom UDP or TCP transport • All this will be reflected in the SDP negotiation • WebRTC only supports m=application + UDP/DTLS/SCTP • It’s the only non audio/video thing it can negotiate • A gateway will have more work to do than with RTP audio/video • Translate between SDP formats (e.g., custom protocol ↔ application) • Gateway the protocol itself (e.g., RTP/T.140 ↔ data channel)
  • 23.
    That’s better, butstill not enough! • Non audio/video protocols have their own technical requirements • RTT and T.38 will have custom RTP packetization rules • BFCP/MSRP/others will require custom UDP or TCP transport • All this will be reflected in the SDP negotiation • WebRTC only supports m=application + UDP/DTLS/SCTP • It’s the only non audio/video thing it can negotiate • A gateway will have more work to do than with RTP audio/video • Translate between SDP formats (e.g., custom protocol ↔ application) • Gateway the protocol itself (e.g., RTP/T.140 ↔ data channel)
  • 24.
    A practical example:Real-Time Text (T.140) • Text transmitted instantly, as it is typed or created • ITU-T T.140 (Protocol for multimedia application text conversation) • Allows for real-time editing (e.g., backspace, rewriting) • T.140 messages transported over RTP • RFC 4103 (RTP Payload for Text Conversation) • Redundancy implemented via RED (RFC 2198) Specification to use T.140 over data channels • T.140 Real-Time Text Conversation over WebRTC Data Channels (RFC 8865) • https://www.rfc-editor.org/rfc/rfc8865.html
  • 25.
    A practical example:Real-Time Text (T.140) • Text transmitted instantly, as it is typed or created • ITU-T T.140 (Protocol for multimedia application text conversation) • Allows for real-time editing (e.g., backspace, rewriting) • T.140 messages transported over RTP • RFC 4103 (RTP Payload for Text Conversation) • Redundancy implemented via RED (RFC 2198) Specification to use T.140 over data channels • T.140 Real-Time Text Conversation over WebRTC Data Channels (RFC 8865) • https://www.rfc-editor.org/rfc/rfc8865.html
  • 26.
    A practical example:Real-Time Text (T.140) • Text transmitted instantly, as it is typed or created • ITU-T T.140 (Protocol for multimedia application text conversation) • Allows for real-time editing (e.g., backspace, rewriting) • T.140 messages transported over RTP • RFC 4103 (RTP Payload for Text Conversation) • Redundancy implemented via RED (RFC 2198) Specification to use T.140 over data channels • T.140 Real-Time Text Conversation over WebRTC Data Channels (RFC 8865) • https://www.rfc-editor.org/rfc/rfc8865.html
  • 27.
    SIP plugin inJanus normally...
  • 28.
    SIP plugin inJanus + RTT https://github.com/meetecho/janus-gateway/pull/3231
  • 29.
    Example: SDP offerfrom SIP/RTT endpoint v=0 o=Lorenzo_Miniero 1 1 IN IP4 192.168.1.74 s=Omnitor_SDP_v1.1 c=IN IP4 192.168.1.74 t=0 0 m=text 1024 RTP/AVP 99 98 a=rtpmap:99 red/1000 a=fmtp:99 98/98/98 a=rtpmap:98 t140/1000
  • 30.
    Example: SDP offerto WebRTC endpoint v=0 o=Lorenzo_Miniero 1 1 IN IP4 192.168.1.74 s=Omnitor_SDP_v1.1 t=0 0 a=group:BUNDLE data a=msid-semantic: WMS janus m=application 9 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.168.1.74 a=sendrecv a=sctp-port:5000 a=mid:0 [.. ICE/DTLS details follow ..]
  • 31.
  • 32.
    Testing: Janus SIPdemo (WebRTC) https://www.meetecho.com/blog/realtime-text-sip-and-webrtc/
  • 33.
    A more complexexample: MSRP • Instant Messaging protocol negotiated in SIP/SDP • RFC 4975 (Message Session Relay Protocol) • Requires a reliable transport (e.g., TCP) • Used m=message m-line type for negotiation • Protocol must be TCP/MSRP or TCP/TLS/MSRP • path attribute defines endpoints Specification to use MSRP over data channels • Message Session Relay Protocol (MSRP) over Data Channels (RFC 8873) • https://www.rfc-editor.org/rfc/rfc8873.html
  • 34.
    A more complexexample: MSRP • Instant Messaging protocol negotiated in SIP/SDP • RFC 4975 (Message Session Relay Protocol) • Requires a reliable transport (e.g., TCP) • Used m=message m-line type for negotiation • Protocol must be TCP/MSRP or TCP/TLS/MSRP • path attribute defines endpoints Specification to use MSRP over data channels • Message Session Relay Protocol (MSRP) over Data Channels (RFC 8873) • https://www.rfc-editor.org/rfc/rfc8873.html
  • 35.
    A more complexexample: MSRP • Instant Messaging protocol negotiated in SIP/SDP • RFC 4975 (Message Session Relay Protocol) • Requires a reliable transport (e.g., TCP) • Used m=message m-line type for negotiation • Protocol must be TCP/MSRP or TCP/TLS/MSRP • path attribute defines endpoints Specification to use MSRP over data channels • Message Session Relay Protocol (MSRP) over Data Channels (RFC 8873) • https://www.rfc-editor.org/rfc/rfc8873.html
  • 36.
    Much more complexto handle than RTT • T.140 still uses RTP (and UDP) • Easier to integrate in existing Janus SIP plugin bridging • Complexity mostly in SDP translation (and maybe RED) • MSRP requires a reliable transport protocol • With TCP, who connects to who? • Integrating TCP with UDP poll loop can be tricky (head-of-line blocking) • On the WebRTC side, we need to be able to provide MSRP path • It won’t be in the SDP (attribute stripped) and dcsa unsupported by browsers • Needs out of band (Janus SIP plugin API?) mechanism for that
  • 37.
    Much more complexto handle than RTT • T.140 still uses RTP (and UDP) • Easier to integrate in existing Janus SIP plugin bridging • Complexity mostly in SDP translation (and maybe RED) • MSRP requires a reliable transport protocol • With TCP, who connects to who? • Integrating TCP with UDP poll loop can be tricky (head-of-line blocking) • On the WebRTC side, we need to be able to provide MSRP path • It won’t be in the SDP (attribute stripped) and dcsa unsupported by browsers • Needs out of band (Janus SIP plugin API?) mechanism for that
  • 38.
    Much more complexto handle than RTT • T.140 still uses RTP (and UDP) • Easier to integrate in existing Janus SIP plugin bridging • Complexity mostly in SDP translation (and maybe RED) • MSRP requires a reliable transport protocol • With TCP, who connects to who? • Integrating TCP with UDP poll loop can be tricky (head-of-line blocking) • On the WebRTC side, we need to be able to provide MSRP path • It won’t be in the SDP (attribute stripped) and dcsa unsupported by browsers • Needs out of band (Janus SIP plugin API?) mechanism for that
  • 39.
    SIP plugin inJanus + MSRP https://github.com/meetecho/janus-gateway/tree/sip-msrp
  • 40.
    Example: SDP offerfrom Blink (SIP/MSRP) v=0 o=- 3922178296 3922178296 IN IP4 192.168.1.74 s=Blink 5.5.1 (Linux) t=0 0 m=message 2855 TCP/MSRP * c=IN IP4 192.168.1.74 a=path:msrp://192.168.1.74:2855/59a83c96684d4fc5fa41;tcp a=accept-types:message/cpim text/* image/* application/im-iscomposing+xml a=accept-wrapped-types:text/* image/* application/im-iscomposing+xml a=setup:active
  • 41.
    Example: SDP offerto WebRTC endpoint v=0 o=- 3922178296 3922178296 IN IP4 192.168.1.74 s=Blink 5.5.1 (Linux) t=0 0 a=group:BUNDLE 0 a=extmap-allow-mixed a=msid-semantic: WMS * m=application 9 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.168.1.74 a=sendrecv a=sctp-port:5000 [.. ICE/DTLS details follow ..]
  • 42.
    Testing: Janus SIPdemo (WebRTC)
  • 43.
    What’s next? • BothRTT and MSRP “work” in Janus, but there’s a lot to do! • RTT is in a better shape, but needs testing with actual endpoints • MSRP in a more embrional stage, needs a lot of love • Multiple protocols in same PeerConnection not supported yet either • Data channels allow for that (single m-line, multiple labels) • We need better mapping when dealing with SDP translation • Maybe add support for other protocols? • Not sure what’s really used and needed, out there • Is this effort really worth it, though? • Probably yes for RTT (Emergency Services mandate it) • Other protocols may have better “solutions” already
  • 44.
    What’s next? • BothRTT and MSRP “work” in Janus, but there’s a lot to do! • RTT is in a better shape, but needs testing with actual endpoints • MSRP in a more embrional stage, needs a lot of love • Multiple protocols in same PeerConnection not supported yet either • Data channels allow for that (single m-line, multiple labels) • We need better mapping when dealing with SDP translation • Maybe add support for other protocols? • Not sure what’s really used and needed, out there • Is this effort really worth it, though? • Probably yes for RTT (Emergency Services mandate it) • Other protocols may have better “solutions” already
  • 45.
    What’s next? • BothRTT and MSRP “work” in Janus, but there’s a lot to do! • RTT is in a better shape, but needs testing with actual endpoints • MSRP in a more embrional stage, needs a lot of love • Multiple protocols in same PeerConnection not supported yet either • Data channels allow for that (single m-line, multiple labels) • We need better mapping when dealing with SDP translation • Maybe add support for other protocols? • Not sure what’s really used and needed, out there • Is this effort really worth it, though? • Probably yes for RTT (Emergency Services mandate it) • Other protocols may have better “solutions” already
  • 46.
    What’s next? • BothRTT and MSRP “work” in Janus, but there’s a lot to do! • RTT is in a better shape, but needs testing with actual endpoints • MSRP in a more embrional stage, needs a lot of love • Multiple protocols in same PeerConnection not supported yet either • Data channels allow for that (single m-line, multiple labels) • We need better mapping when dealing with SDP translation • Maybe add support for other protocols? • Not sure what’s really used and needed, out there • Is this effort really worth it, though? • Probably yes for RTT (Emergency Services mandate it) • Other protocols may have better “solutions” already
  • 47.
    Thanks! Questions? Comments? Contacts •https://fosstodon.org/@lminiero • https://twitter.com/elminiero • https://twitter.com/meetecho • https://www.meetecho.com/blog/