Pure Go implementation of the WebRTC API

Overview

Pion WebRTC
Pion WebRTC

A pure Go implementation of the WebRTC API

Pion webrtc Sourcegraph Widget Slack Widget Twitter Widget
Build Status PkgGoDev Coverage Status Go Report Card Codacy Badge License: MIT


New Release

Pion WebRTC v3.0.0 has been released! See the release notes to learn about new features and breaking changes.

If you aren't able to upgrade yet check the tags for the latest v2 release.

We would love your feedback! Please create GitHub issues or join the Slack channel to follow development and speak with the maintainers.


Usage

Go Modules are mandatory for using Pion WebRTC. So make sure you set export GO111MODULE=on, and explicitly specify /v2 or /v3 when importing.

example applications contains code samples of common things people build with Pion WebRTC.

example-webrtc-applications contains more full featured examples that use 3rd party libraries.

awesome-pion contains projects that have used Pion, and serve as real world examples of usage.

GoDoc is an auto generated API reference. All our Public APIs are commented.

FAQ has answers to common questions. If you have a question not covered please ask in Slack we are always looking to expand it.

Now go build something awesome! Here are some ideas to get your creative juices flowing:

  • Send a video file to multiple browser in real time for perfectly synchronized movie watching.
  • Send a webcam on an embedded device to your browser with no additional server required!
  • Securely send data between two servers, without using pub/sub.
  • Record your webcam and do special effects server side.
  • Build a conferencing application that processes audio/video and make decisions off of it.
  • Remotely control a robots and stream its cameras in realtime.

Want to learn more about WebRTC?

Check out WebRTC for the Curious. A book about WebRTC in depth, not just about the APIs. Learn the full details of ICE, SCTP, DTLS, SRTP, and how they work together to make up the WebRTC stack.

This is also a great resource if you are trying to debug. Learn the tools of the trade and how to approach WebRTC issues.

This book is vendor agnostic and will not have any Pion specific information.

Features

PeerConnection API

  • Go implementation of webrtc-pc and webrtc-stats
  • DataChannels
  • Send/Receive audio and video
  • Renegotiation
  • Plan-B and Unified Plan
  • SettingEngine for Pion specific extensions

Connectivity

  • Full ICE Agent
  • ICE Restart
  • Trickle ICE
  • STUN
  • TURN (UDP, TCP, DTLS and TLS)
  • mDNS candidates

DataChannels

  • Ordered/Unordered
  • Lossy/Lossless

Media

  • API with direct RTP/RTCP access
  • Opus, PCM, H264, VP8 and VP9 packetizer
  • API also allows developer to pass their own packetizer
  • IVF, Ogg, H264 and Matroska provided for easy sending and saving
  • getUserMedia implementation (Requires Cgo)
  • Easy integration with x264, libvpx, GStreamer and ffmpeg.
  • Simulcast
  • SVC
  • NACK
  • Full loss recovery and congestion control is not complete, see pion/interceptor for progress
    • See ion for how an implementor can do it today

Security

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA for DTLS v1.2
  • SRTP_AEAD_AES_256_GCM and SRTP_AES128_CM_HMAC_SHA1_80 for SRTP
  • Hardware acceleration available for GCM suites

Pure Go

  • No Cgo usage
  • Wide platform support
    • Windows, macOS, Linux, FreeBSD
    • iOS, Android
    • WASM see examples
    • 386, amd64, arm, mips, ppc64
  • Easy to build Numbers generated on Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
    • Time to build examples/play-from-disk - 0.66s user 0.20s system 306% cpu 0.279 total
    • Time to run entire test suite - 25.60s user 9.40s system 45% cpu 1:16.69 total
  • Tools to measure performance provided

Roadmap

The library is in active development, please refer to the roadmap to track our major milestones. We also maintain a list of Big Ideas these are things we want to build but don't have a clear plan or the resources yet. If you are looking to get involved this is a great place to get started! We would also love to hear your ideas! Even if you can't implement it yourself, it could inspire others.

Community

Pion has an active community on the Slack.

Follow the Pion Twitter for project updates and important WebRTC news.

We are always looking to support your projects. Please reach out if you have something to build! If you need commercial support or don't want to use public methods you can contact us at [email protected]

Contributing

Check out the contributing wiki to join the group of amazing people making this project possible:

License

MIT License - see LICENSE for full text

Issues
  • Support 1:1 NAT option

    Support 1:1 NAT option

    Summary

    Motivation

    Pion could be used in C/S topology, one end is a client and the other end is a server (just like Janus G/W does). But in this case, the server must have a routable (public) IP address. Many server environments may not have access to public IP address to bind to the local interface.

    Janus provides the following option. Pion could provide something equivalent.

        -1, --nat-1-1=ip              Public IP to put in all host candidates,
                                      assuming a 1:1 NAT is in place (e.g., Amazon
                                      EC2 instances, default=none)
    

    Describe alternatives you've considered

    Use STUN server for the server-side nodes.

    opened by enobufs 37
  • Move transceiver selection inside SetRemoteDescription and CreateOffer

    Move transceiver selection inside SetRemoteDescription and CreateOffer

    Description

    This tries to better match the JSEP spec and will fix at least two issues: #1171 and #1178

    • Move transceiver selection/creation in SetRemoteDescription and CreateOffer
    • In SetRemoteDescription also create new Transceivers of type recvonly when no satisfying transceiver is available
    • In CreateOffer generate unique mid in number format avoiding possible collisions with remote provide mids and to also already handle a future implementation of m= section rejection and reuse
    • Now generateMatchedSDP will just find the transceivers with the required mid since they are already selected previously.

    More details in these extract from JSEP:

    JSEP 5.10 (Applying a Remote Description) says:

    For each m= section, the following steps MUST be performed
    
    [...]
    
    If the m= section is not associated with any RtpTransceiver
    (possibly because it was dissociated in the previous step),
    either find an RtpTransceiver or create one according to the
    following steps:
    

    JSEP 5.2 (Constructing an Offer) says:

    [...]
    
    An m= section is generated for each RtpTransceiver
    that has been added to the PeerConnection, excluding any stopped
    RtpTransceivers;
    

    Note that we are currently directly associating a mid to a transceiver in CreateOffer, instead the spec says to also keep a m= section index mapping to a transceiver and set the transceiver mid only when applying the local description. This is needed to support rollback of proposed offer/answer but currently we don't have support and tests for rollback situations.

    Reference issue

    Fixes #1171 Fixes #1178

    opened by sgotti 24
  • Exchange messages using Windows environment

    Exchange messages using Windows environment

    Hi, we are trying to sending message using windows environment.

    We have 1 server instance run on the Windows from NAT network and other one client instance run on the Windows from NAT network on other PC.

    As the result we cant exhange messages and we cant see any errors.

    Can you help as run this solution using Windows enviroment, because is it important for us?

    If you need we can gve you as information you want.

    Thanks.

    PS we are using this example: https://github.com/pions/webrtc/tree/master/examples/pion-to-pion

    backlog bug 
    opened by netwer 23
  • How to replace gstreamer from the examples gstreamer-receive and gstreamer-send

    How to replace gstreamer from the examples gstreamer-receive and gstreamer-send

    How could I replace gstreamer with something more lightweight c lib

    or pure go lib if I only want to work with audio (non-GUI app)?

    Any ideas?

    Thanks in advance :)

    triaged 
    opened by joeky888 23
  • PeerConnection OnTrack callback never invoked

    PeerConnection OnTrack callback never invoked

    Your environment.

    • Version: v2.1.8
    • Browser: None
    • Other Information - I am trying to create a softphone using SIP and this library. The remote SIP & RTC service have no problem, because I have done a softphone using Node.js: https://github.com/ringcentral/ringcentral-softphone-js . I am trying to make a GoLang version, but I am stuck.

    What did you do?

    I have written the following code: https://github.com/ringcentral/ringcentral-softphone-go/blob/master/softphone.go#L137-L220

    Just for your reference, here is the Node.js version of the GoLang code: https://github.com/ringcentral/ringcentral-softphone-js/blob/ce833c613d5e4bb959235e37addefd10cc9cb81e/index.js#L140-L177 . The Node.js code works like a charm.

    What did you expect?

    I expect that the peerConnection.OnTrack callback function will be invoked so that I can get the input audio

    What happened?

    peerConnection.OnTrack never invoked and I am stuck.

    Some questions:

    Could it because I specify the wrong codec? If so, I expect some error message like: no codec to handle the remote track. remote SDP sample:

    v=0
    o=- 5305405169010475891 908790132696250821 IN IP4 104.245.57.182
    s=SmcSip
    c=IN IP4 104.245.57.182
    t=0 0
    m=audio 20040 RTP/SAVPF 109 111 18 0 8 9 96 101
    a=rtpmap:109 OPUS/16000
    a=fmtp:109 useinbandfec=1
    a=rtcp-fb:109 ccm tmmbr
    a=rtpmap:111 OPUS/48000/2
    a=fmtp:111 useinbandfec=1
    a=rtcp-fb:111 ccm tmmbr
    a=rtpmap:18 g729/8000
    a=fmtp:18 annexb=no
    a=rtpmap:0 pcmu/8000
    a=rtpmap:8 pcma/8000
    a=rtpmap:9 g722/8000
    a=rtpmap:96 ilbc/8000
    a=fmtp:96 mode=20
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15
    a=sendrecv
    a=rtcp:20041
    a=rtcp-mux
    a=setup:actpass
    a=fingerprint:sha-1 E2:F8:90:C6:37:7E:82:17:3C:63:CF:55:68:4E:1D:16:17:2C:D9:4D
    a=ice-ufrag:atwbXWRm
    a=ice-pwd:32SCWdSoU7BgkXxet5g5mlId5E
    a=candidate:muEZ8Bb5Zhy8XFSL 1 UDP 2130706431 104.245.57.182 20040 typ host
    a=candidate:muEZ8Bb5Zhy8XFSL 2 UDP 2130706430 104.245.57.182 20041 typ host
    

    How can I port the Node.JS code to GoLang? Because I know Node.js version works like charm. And the code even works in browser (with browser WebRTC). So if pion/webrtc is compatible with browser WebRTC, I should be able to get this GoLang version work.

    Could it becuase of this https://github.com/pion/webrtc/issues/879? I temporarily worked around the issue: https://github.com/ringcentral/ringcentral-softphone-go/blob/master/softphone.go#L133

    opened by tylerlong 23
  • Regression: connection failed

    Regression: connection failed

    The latest working commit c87c3ca45386f2889887ac70633d71841793bc3c Current master doesn't establish connection at all, I think issue related because of latest ICE changes. Tested with chrome browser. Network map: client -> NAT -> server with real ip

    blocked bug 
    opened by Bogdan-D 23
  • media: support sending MediaStreams with multiple tracks

    media: support sending MediaStreams with multiple tracks

    Currently the media stream labels are hardcoded in the SDP offer and answer generation. The RTCPeerConnection.AddTrack should be extended to support adding media stream labels.

    TODO

    • [ ] Add a variadic streams argument to the AddTrack method as specified in the RTP Media API
    • [ ] Store the media stream ids on the RTCTrack object as specified here
    • [ ] Add the media streams to the SDP offer and answer. Some of the required logic already exists. However, the stream label is currently hardcoded to the track label. The procedure is specified in the JSEP spec
    difficulty:easy good first issue help wanted 
    opened by Sean-Der 23
  • interceptor POC

    interceptor POC

    Updated interceptor design based on TrackLocal:

    Changes:

    1. Interceptor now have Bind methods similar to track, which are called for every track (local/remote) for rtp, and once per peerconnection for rtcp.
    2. Added interceptors separately to API, instead of under setting engine. Did this because interceptors must be created per peerconnection, and InterceptorFactory seemed confusing. Also API was already a depedency of Receiver/Sender, so this was was much simpler. Similarly to MediaEngine, Interceptors now must be configured for each PeerConnection and added to API. Default interceptors can later be added in NewAPI method.
    3. Instead of using interfaces with single a single function (eg: RTPWriter with a single WriteRTP function), I use function types. This makes implementing an interceptor simpler, because there is no need to create a separate struct for each interface (inline functions can be used instead).
    type WriteRTP func(p *rtp.Packet, attributes map[interface{}]interface{}) (int, error)
    type ReadRTP func() (*rtp.Packet, map[interface{}]interface{}, error)
    type WriteRTCP func(pkts []rtcp.Packet, attributes map[interface{}]interface{}) (int, error)
    type ReadRTCP func() ([]rtcp.Packet, map[interface{}]interface{}, error)
    
    type Interceptor interface {
    	BindReadRTCP(read ReadRTCP) ReadRTCP     // TODO: call this
    	BindWriteRTCP(write WriteRTCP) WriteRTCP // TODO: call this
    
    	BindLocalTrack(ctx *TrackLocalContext, write WriteRTP) WriteRTP
    	UnbindLocalTrack(ctx *TrackLocalContext)
    
    	BindRemoteTrack(ctx *TrackRemoteContext, read ReadRTP) ReadRTP
    	UnbindRemoteTrack(ctx *TrackRemoteContext)
    
    	io.Closer
    }
    

    Questions:

    1. Please see interceptor_peerconnection.go and interceptor_track_remote.go. They are quite ugly. I'm open to any suggestions.
    2. ReadRTCP is currently present on both RTPSender and RTPReceiver, while WriteRTCP is on PeerConnection. I think it would make much more sense to move ReadRTCP to PeerConnection as well. The current solution using DestinationSSRC() method is very opionated and causes some rtcp packets to be duplicated (in case they belong to multiple ssrc, or they are in a batch with another rtcp packet that belong to a different rtcp, see session_rtcp.go/destinationSSRC). In fact in our project we went to great length to undo this behaviour and get a single ReadRTCP method, without packet duplications. Is there any plan to modify this behaviour? (It would make calling BindReadRTCP in the Interceptor much easier).

    Any suggestions are welcome.

    @Sean-Der @at-wat please check

    opened by masterada 21
  • community: related projects

    community: related projects

    This ticket tracks projects related to pions. These can be projects using pions or projects we want to/are contributing WebRTC support to.

    Media API

    DataChannel

    Unknown

    Other language implementations

    Organize TODO

    • https://github.com/Antonito/gfile
    • https://github.com/pion/asciirtc
    • https://github.com/maxmcd/webtty
    • https://github.com/rtctunnel/rtctunnel
    • https://github.com/nobonobo/ssh-p2p
    • https://github.com/mxseba/rtc-ssh
    • https://github.com/poi5305/go-yuv2webRTC
    • https://github.com/rian-hotate/tetoris
    • https://github.com/schollz/webrtc-transfer
    • https://github.com/machinesworking/myhome
    • https://github.com/wwl33695/myrtc
    • https://github.com/takutakahashi/wg-connect
    • https://github.com/open-domophone/soft-omega2
    • https://github.com/mtojek/filegate
    • https://github.com/porjo/babelcast
    • https://github.com/porjo/mumblet
    • https://github.com/cretz/myscreen.live
    • https://github.com/deepch/RTSPtoWebRTC
    • https://github.com/hoernschen/goat
    • https://github.com/discordianfish/infisk8-server
    • https://github.com/edwintcloud/classmate
    • https://github.com/nacgarg/stereo
    • https://github.com/mtharp/gunk
    • https://github.com/bashawhm/TheHarmonicInternetNoiseGiver
    • https://github.com/s8sg/satellite

    This issue can be used for tracking. Please use the Golang Slack #pion channel or mailing list for discussions.

    triaged 
    opened by backkem 21
  • Add CertificateFromPEM and PEM() to Certificate

    Add CertificateFromPEM and PEM() to Certificate

    Allow for easier usage of a pre-existing certificate

    opened by Sean-Der 20
  • Fixes ReplaceTrack

    Fixes ReplaceTrack

    When ReplaceTrack was set previously to nil it would be impossible to ReplaceTrack again with a non-nil value as r.track was set to nil.

    opened by digitalix 1
  • Update codecov/codecov-action action to v2

    Update codecov/codecov-action action to v2

    WhiteSource Renovate

    This PR contains the following updates:

    | Package | Type | Update | Change | |---|---|---|---| | codecov/codecov-action | action | major | v1 -> v2 |


    Release Notes

    codecov/codecov-action

    v2

    Compare Source


    Configuration

    📅 Schedule: At any time (no schedule defined).

    🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

    Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

    🔕 Ignore: Close this PR and you won't be reminded about this update again.


    • [ ] If you want to rebase/retry this PR, check this box.

    This PR has been generated by WhiteSource Renovate. View repository job log here.

    opened by renovate[bot] 0
  • DTLS start before ICE state change to non-NEW in v3.0.29

    DTLS start before ICE state change to non-NEW in v3.0.29

    Your environment.

    • Version: go 1.14 webrtc v3.0.29
    • Browser: include version
    • Other Information - stacktraces, related issues, suggestions how to fix, links for us to have context

    What did you do?

    What did you expect?

    What happened?

    DTLS will check the connection status of the ICE before the handshake, but the connection status of ICE has not changed to non-NEW. So, DTLS returns an error without doing anything. WebRTC Client will timeout during DTLS handshake. ICE change state in other goroutinue.

    DTLS prepareTransport checking the connection status of the ICE

    func (t *DTLSTransport) Start(remoteParameters DTLSParameters) error {
    	prepareTransport := func() (DTLSRole, *dtls.Config, error) {
    		t.lock.Lock()
    		defer t.lock.Unlock()
    
    		if err := t.ensureICEConn(); err != nil {
    			return DTLSRole(0), nil, err
    		}
    
    		if t.state != DTLSTransportStateNew {
    			return DTLSRole(0), nil, &rtcerr.InvalidStateError{Err: fmt.Errorf("%w: %s", errInvalidDTLSStart, t.state)}
    		}
    .......
    	}
    
    	var dtlsConn *dtls.Conn
    	dtlsEndpoint := t.iceTransport.newEndpoint(mux.MatchDTLS)
    	role, dtlsConfig, err := prepareTransport()
    	if err != nil {
    		return err
    	}
    

    ensure ICE connection check ICE state != NEW

    func (t *DTLSTransport) ensureICEConn() error {
    	if t.iceTransport == nil || t.iceTransport.State() == ICETransportStateNew {
    		return errICEConnectionNotStarted
    	}
    
    	return nil
    }
    

    But ICE real change state in other goroutinue

    func (a *Agent) startOnConnectionStateChangeRoutine() {
    	........
    
    	go func() {
    		for {
    			select {
    			case s, isOpen := <-a.chanState:
    				if !isOpen {
    					for c := range a.chanCandidate {
    						a.onCandidate(c)
    					}
    					return
    				}
    				a.onConnectionStateChange(s)
    
    			case c, isOpen := <-a.chanCandidate:
    				if !isOpen {
    					for s := range a.chanState {
    						a.onConnectionStateChange(s)
    					}
    					return
    				}
    				a.onCandidate(c)
    			}
    		}
    	}()
    }
    
    opened by vicvon 0
  • Update CI configs to v0.5.8

    Update CI configs to v0.5.8

    Update lint scripts and CI configs.

    opened by pionbot 2
  • Add WithTailChecker option to depacketizer

    Add WithTailChecker option to depacketizer

    While Galene is now using its own samplebuilder, it would be good to avoid splitting the community by having the public interfaces diverge too much. This means preventing internal details of the samplebuilder from leaking into other parts of Pion.

    An earlier commit sneaked in the IsDetectedFinalPacketInSequence method to the rtp.Depacketizer interface. Not only does this break compatibility with earlier versions, it requires every single implementation of rtp.Depacketizer to implement essentially the same code. It is also conceptually wrong, as the job of finding the end of the packet belongs in the samplebuilder, not in the depacketizer.

    In this commit, we treat partition ends similarly to partition starts: we add a new callback to the samplebuilder whose role is to determine whether a packet ends a partition. A new option WithPartitionTailChecker, analogous to WithPartitionHeadChecker, can be used to set that field. Tests are adapted.

    opened by jech 1
  • Update module github.com/pion/rtp to v2

    Update module github.com/pion/rtp to v2

    WhiteSource Renovate

    This PR contains the following updates:

    | Package | Type | Update | Change | |---|---|---|---| | github.com/pion/rtp | require | major | v1.6.5 -> v2.0.0 |


    Release Notes

    pion/rtp

    v2.0.0

    Compare Source


    Configuration

    📅 Schedule: At any time (no schedule defined).

    🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

    Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

    🔕 Ignore: Close this PR and you won't be reminded about this update again.


    • [ ] If you want to rebase/retry this PR, check this box.

    This PR has been generated by WhiteSource Renovate. View repository job log here.

    opened by renovate[bot] 2
  • Enable VP8 PictureID by default

    Enable VP8 PictureID by default

    For using in SLI.

    Reference issue

    Requires https://github.com/pion/rtp/pull/142

    opened by at-wat 3
  • Fix AddTrack transceiver reuse per W3C specs

    Fix AddTrack transceiver reuse per W3C specs

    According to W3C specifications, the transceiver can be reused if "The sender has never been used to send. More precisely, the [[CurrentDirection]] slot of the RTCRtpTransceiver associated with the sender has never had a value of "sendrecv" or "sendonly"". Current implementation does not have CurrentDirection slot, so the flag usedToSend is set on setDirection change. This fixes #1843 and maybe other issues (for us it fixes other two issues when reusing transceiver, eg clients going and coming back to a conference). This has been done on the v2 branch because we currently don't have the resources to switch our software to v3 and test it there. Looking at the source (master) seems this kind of issue is still there.

    opened by EdoaLive 1
  • Implement DTLS restart

    Implement DTLS restart

    https://github.com/pion/srtp/pull/148 is needed before being able to merge

    ~~The unit test needs https://github.com/pion/transport/pull/141~~

    Fixes #1636

    ~~I'm not sure about if t.state != DTLSTransportStateNew && t.state != DTLSTransportStateClosed, one other option would be to set the state to New before restarting, but I don't want to trigger a StateChanged event – which could be wrong.~~ Turns out that's what libwebrtc does

    Also the condition on which DTLS is restarted might be too permissive – but it doesn't seem to break any test so far.

    opened by Antonito 4
  • pion/webrtc v2.2.26 wrong transceivers reuse, cannot re-add removed tracks on receiver side.

    pion/webrtc v2.2.26 wrong transceivers reuse, cannot re-add removed tracks on receiver side.

    Your environment.

    • Version: Ubuntu 20.04.2 LTS 64-bit - GNOME Version 3.36.8
    • Browser: Google Chrome Version 91.0.4472.77 (Official Build) (64-bit)
    • Used pion versions:
    github.com/pion/dtls/v2 v2.0.4 // indirect
    github.com/pion/quic v0.1.4 // indirect
    github.com/pion/rtcp v1.2.6
    github.com/pion/sctp v1.7.11 // indirect
    github.com/pion/srtp v1.5.2 // indirect
    github.com/pion/stun v0.3.5
    github.com/pion/transport v0.12.0 // indirect
    github.com/pion/turn/v2 v2.0.5
    github.com/pion/webrtc/v2 v2.2.26
    

    What did you do?

    First of all, thank you for your product and support!

    We are using pion to implement our own SFU.

    We are trying to figure out why, although Chrome's webrtc-internal stats display packet reception, negotiation, and transceiver status change are correct, the audio/video stream doesn't show when tracks are removed and then re-added.

    Steps

    The panelist initiates the call with only the webcam video track (to simplify debugging) and publishes it, attendees joins the call with only the microphone audio track.

    The panelist's audio/video stream is then added to the attendees subscriptions and correctly displayed.

    The broadcast of the panelist's audio/video stream is stopped and the attendees subscriptions are stopped.

    Then the panelist's audio/video stream is added again and the subscriptions restored.

    I am attaching the log of the negotiations on both the panelist and the attendant side and the stats.

    We don't think this is your issue, but it would be great if we could get support to try and understand why the stream isn't being received again.

    EDIT 2021-06-24

    Note that:

    • both negotiations logs are copy/pasted from chrome://webrtc-internals and reflect the javascript side of the client.
    • you can also see the SDP generated by your go implementation of webrtc on calls to setRemoteDescription of logs
    • the add and removal of screen-sharing works correctly even when done multiple times
    • the attendee never remove the initial stream with one track coming from the mic
    • you can also see that the id of the tracks remains the same at the next addition which to my knowledge is not normal behavior
    • we have verified that the track.stop() method is not called for any remote track.

    Obviously any information and suggestions will be welcome.

    We regret not being able to share more information, we are still investigating, and will keep you updated in case we manage to isolate or solve the problem on our side or on your side.

    What did you expect?

    The audio/video stream should be visible again.

    What happened?

    The audio/video stream is not restored.

    panelist-negotiations.txt attendee-negotiations.txt

    panelist-outbound-rtpvideo-stats attendee-inbound-rtpvideo-stats

    opened by marco-sacchi 1
Releases(v3.0.0)
  • v3.0.0(Dec 31, 2020)

    The Pion team is very excited to announce the v3.0.0 release of Pion WebRTC. Pion WebRTC is a Go implementation of WebRTC. If you haven't used it before check out awesome-pion or example-webrtc-applications for what people are doing. We maintain a feature list and other helpful resources in our README.md

    This release includes 264 commits from 43 authors. We reduced sharp edges in the media API, add performance gains in media and datachannel paths and brought ourselves more in alignment with the browser API.

    We do have quite a few breaking changes. Please read them carefully, most of these things can't be caught at compile time. Reading this document could save a lot of time debugging. Each change will have a linked commit. Looking at examples/ in the linked commit should show what code you need to change in your application.

    Breaking Changes

    Trickle ICE is now enabled by default

    Before /v3 Pion WebRTC would gather all candidates before a CreateOffer or CreateAnswer generated a SDP. This would cause a few issues in real world applications. You can read about the benefits of Trickle ICE here

    • Longer call connection times since we blocked for STUN/TURN even if not needed
    • This didn't comply with the WebRTC spec
    • Made it harder for users to filter/process ICE Candidates

    Now you should exchange ICE Candidates that are pushed via the OnICECandidate callback.

    Before

      peerConnection, _ := webrtc.NewPeerConnection(webrtc.Configuration{})
    
      offer, _ := peerConnection.CreateOffer()
      peerConnection.SetLocalDescription(offer)
    
      // Send `offer` to remote peer
      websocket.Write(offer)
    

    After

      peerConnection, _ := webrtc.NewPeerConnection(webrtc.Configuration{})
    
      // Set ICE Candidate handler. As soon as a PeerConnection has gathered a candidate
      // send it to the other peer
      peerConnection.OnICECandidate(func(i *webrtc.ICECandidate) {
        // Send ICE Candidate via Websocket/HTTP/$X to remote peer
      })
    
      // Listen for ICE Candidates from the remote peer
      peerConnection.AddICECandidate(remoteCandidate)
    
      // You still signal like before, but `CreateOffer` will be much faster
      offer, _ := peerConnection.CreateOffer()
      peerConnection.SetLocalDescription(offer)
    
      // Send `offer` to remote peer
      websocket.Write(offer)
    

    If you are unable to migrate we have provided a helper function to simulate the pre-v3 behavior.

    Helper function to simulate non-trickle ICE

      peerConnection, _ := webrtc.NewPeerConnection(webrtc.Configuration{})
    
      offer, _ := peerConnection.CreateOffer()
    
      // Create channel that is blocked until ICE Gathering is complete
      gatherComplete := webrtc.GatheringCompletePromise(peerConnection)
      peerConnection.SetLocalDescription(offer)
      <-gatherComplete
    
      // Send `LocalDescription` to remote peer
      // This is the offer but populated with all the ICE Candidates
      websocket.Write(*peerConnection.LocalDescription())
    

    This was changed with bb3aa9

    A data channel is no longer implicitly created with a PeerConnection

    Before /v3 Pion WebRTC would always insert a application Media Section. This means that an offer would work even if you didn't create a DataChannel or Transceiver, in /v3 you MUST create a DataChannel or track first. To better illustrate these are two SDPs, each from a different version of Pion WebRTC

    /v2 SDP with no CreateDataChannel

    v=0
    o=- 8334017457074456852 1596089329 IN IP4 0.0.0.0
    s=-
    t=0 0
    a=fingerprint:sha-256 91:B0:3A:6E:9E:43:9A:9D:1B:71:17:7D:FB:D0:5C:81:12:6E:61:D5:6C:BF:92:E8:8D:04:F5:92:EF:62:36:C9
    a=group:BUNDLE 0
    m=application 9 DTLS/SCTP 5000
    c=IN IP4 0.0.0.0
    a=setup:actpass
    a=mid:0
    a=sendrecv
    a=sctpmap:5000 webrtc-datachannel 1024
    a=ice-ufrag:yBlrlyMmuDdCfawp
    a=ice-pwd:RzlouYCNYDNpPLJLdddFtUkMVpKVLYWz
    a=candidate:foundation 1 udp 2130706431 192.168.1.8 51147 typ host generation 0
    a=candidate:foundation 2 udp 2130706431 192.168.1.8 51147 typ host generation 0
    a=end-of-candidates
    

    /v3 SDP with no CreateDataChannel

    v=0
    o=- 8628031010413059766 1596089396 IN IP4 0.0.0.0
    s=-
    t=0 0
    a=fingerprint:sha-256 64:79:7C:73:6B:8A:CF:34:9D:D0:9C:6B:31:07:44:0A:CD:56:F0:74:62:72:D4:23:D5:BC:B2:C9:46:55:C5:A3
    a=group:BUNDLE
    

    To simulate the old functionality, call CreateDataChannel after creating your PeerConnection and before calling anything else.

    This was changed with abd6a3

    Track is now an interface

    The design of the Track API in /v3 has been updated to accommodate more use cases and reduce the sharp edges in the API. Before we used one structure to represent incoming and outgoing media. This didn't match with how WebRTC actually works. In WebRTC a track isn't bi-directional. Having Read and Write on the same structure was confusing.

    Split Track into TrackLocal and TrackRemote

    Now we have TrackLocal and TrackRemote. TrackLocal is used to send media, TrackRemote is used to receive media.

    TrackRemote has a similar API to /v2. It has Read and ReadRTP and code will continue to work with just a name change Track -> TrackRemote

    TrackLocal is now an interface, and will require more work to port. For existing code you will want to use one of the TrackLocal implementations. NewLocalTrackStaticSample or NewLocalTrackStaticRTP depending on what type of data you were sending before.

    Code that looks like

      videoTrack, err := peerConnection.NewTrack(payloadType, randutil.NewMathRandomGenerator().Uint32(), "video", "pion")
    

    Needs to become like one of the following

      videoTrack, err := webrtc.NewTrackLocalStaticSample(webrtc.RTPCodecCapability{MimeType: "video/vp8"}, "video", "pion")
    
      videoTrack, err := webrtc.NewTrackLocalStaticRTP(webrtc.RTPCodecCapability{MimeType: "video/vp8"}, "video", "pion")
    

    Users no longer have to manage SSRC/PayloadType

    When creating a Track you don't need to know these values. When writing packets you don't need to pull these values either. Internally we make sure that everything is properly set. This means that mediaengine.PopulateFromSDP has been removed, and you can delete any code that does this.

    Other packages can satisfy LocalTrack

    pion/mediadevices now can provide an API that feels like getUserMedia in the browser. Before it wasn't able to generate anything that pion/webrtc could directly call AddTrack on.

    A user could also implement LocalTrack and and add custom behavior.

    MediaEngine API has changed

    We now use data structures from the W3C to configure available codecs and header extensions. You can also define your own MimeTypes, allowing you to send any codec you wish! pion/webrtc can support for a new codec with just calls to the public API.

    Before

      m.RegisterCodec(webrtc.NewRTPOpusCodec(webrtc.DefaultPayloadTypeOpus, 48000))
      m.RegisterCodec(webrtc.NewRTPVP8Codec(webrtc.DefaultPayloadTypeVP8, 90000))
    

    After

      if err := m.RegisterCodec(webrtc.RTPCodecParameters{
        RTPCodecCapability: webrtc.RTPCodecCapability{MimeType: "video/VP8", ClockRate: 90000, Channels: 0, SDPFmtpLine: "", RTCPFeedback: nil},
        PayloadType:        96,
      }, webrtc.RTPCodecTypeVideo); err != nil {
        panic(err)
      }
      if err := m.RegisterCodec(webrtc.RTPCodecParameters{
        RTPCodecCapability: webrtc.RTPCodecCapability{MimeType: "audio/opus", ClockRate: 48000, Channels: 0, SDPFmtpLine: "", RTCPFeedback: nil},
        PayloadType:        111,
      }, webrtc.RTPCodecTypeAudio); err != nil {
        panic(err)
      }
    

    This was changed with 7edfb7

    New Features

    ICE Restarts

    You can now initiate and accept an ICE Restart! This means that if a PeerConnection goes to Disconnected or Failed because of network interruption it is no longer fatal.

    To use you just need to pass ICERestart: true in your OfferOptions. The answering PeerConnection will then restart also. This is supported in FireFox/Chrome and Mobile WebRTC Clients.

      peerConn, _ := NewPeerConnection(Configuration{})
    
      // PeerConnection goes to ICEConnectionStateFailed
    
      offer, _ := peerConn.CreateOffer(&OfferOptions{ICERestart: true})
    

    This was implemented in f29414

    ICE TCP

    Pion WebRTC now can act as a passive ICE TCP candidates. This means that a remote ICE Agent that supports TCP active can connect to Pion without using UDP. Before the only way to achieve ICE Connectivity in UDP-less networks was by using a TURN server.

    You should still deploy and use a TURN server for NAT traversal.

    Since this isn't part of the standard WebRTC API it requires SettingEngine usage. You can see how to use it in examples/ice-tcp

    This was implemented in 2236dd

    OnNegotationNeeded

    onnegotationneeded is now available. You can define a callback and be notified whenever session negotiation needs to done.

    OnNegotationNeeded in pion/webrtc will behave differently that in the browser because we are operating in a multi-threaded environment. Make sure to have proper locking around your signaling/Session Description handling.

    This was implemented in c5819d

    Simulcast

    You can now send Simulcast feeds to Pion WebRTC! It uses MID/RID identification as defined in ietf-mmusic-sdp-simulcast. An example has been provided at examples/simulcast.

    This was implemented in 6ee528

    SRTP AEAD_AES_128_GCM

    pion/srtp added support for the SRTP Cipher AEAD_AES_128_GCM. Thanks to hardware acceleration you can see up to a 400% performance improvement. You can run benchmarks in pion/srtp to see if your hardware supports it.

    This cipher is on by default, so no change is required. During negotiation Pion WebRTC will prefer this cipher, but fall back to others if not available.

    This was implemented in f871f4

    Interceptor

    v3.0.0 introduces a new Pion specific concept known as a interceptor. A Interceptor is a pluggable RTP/RTCP processor. Via a public API users can easily add and customize operations that are run on inbound/outbound RTP. Interceptors are an interface this means A user could provide their own implementation. Or you can use one of the interceptors Pion will have in-tree.

    We designed this with the following vision.

    • Useful defaults. Nontechnical users should be able to build things without tuning.
    • Don't block unique use cases. We shouldn't paint ourself in a corner. We want to support interesting WebRTC users
    • Allow users to bring their own logic. We should encourage easy changing. Innovation in this area is important.
    • Allow users to learn. Don't put this stuff deep in the code base. Should be easy to jump into so people can learn.

    In this release we only are providing a NACK Generator/Responder interceptor. We will be implementing more and you can import the latest at anytime! This means you can update your pion/interceptor version without having to upgrade pion/webrtc!

    We plan on implementing the following. Check the README in pion/interceptor for the most up to date information.

    WebRTC for the Curious

    The Pion developers started a free book on how WebRTC actually works. It is available at https://webrtcforthecurious.com and is hosted from GitHub. It is A book about WebRTC in depth, not just about the APIs. Learn the full details of ICE, SCTP, DTLS, SRTP, and how they work together to make up the WebRTC stack.

    This is also a great resource if you are trying to debug. Learn the tools of the trade and how to approach WebRTC issues.

    This book is vendor agnostic and will not have any Pion specific information.

    Projects that have been migrated

    See https://github.com/pion/webrtc/issues/1615 for a list of projects that have been migrated to v3.0.0 already. If you are confused about what API changes you need these may be helpful

    Source code(tar.gz)
    Source code(zip)
  • v3.0.0-beta.15(Dec 6, 2020)

  • v3.0.0-beta.11(Nov 4, 2020)

  • v3.0.0-beta.10(Oct 23, 2020)

  • v2.2.0(Feb 16, 2020)

    After 5 months of work (and lots of distraction) the Pion team is excited to announce the release of v2.2.0! This release includes.

    New Features

    DataChannel Performance Improvements

    Thanks to hard work by @enobufs Datachannels have gotten a huge performance improvement. In some cases you will see a 16x improvement in throughput. You can read more about his fantastic work here

    Extend SettingEngine to support SFU use cases

    Pion WebRTC is seeing lots of usage in building SFUs. To support this the SettingEngine has been extended to add even more options. You now have the following flags you can configure

    • SetEphemeralUDPPortRange You can limit the range of UDP ports used to support restrictive networks
    • SetInterfaceFilter You can exclude some interfaces from being used.
    • SetNAT1To1IPs Allows you to set a static IP to replace all host candidates. Useful if you are behind a DNAT, and don't want to make a STUN request for each PeerConnection.
    • SetNetworkTypes You can blacklist TCP, UDP, IPv4 or IPv6. Useful if you know certain configurations will never work.
    • SetLite Enables ICE lite, a minimal version of the ICE protocol. Reduces complexity in situations where full ICE isn't needed like a publicly routeable SFU.

    Thank you @seppo0010, @AeroNotix, @enobufs and @trivigy for your work on this

    TCP TURN Support

    Pion WebRTC now supports creating allocations via UDP, TCP and TLS. Implemented by @enobufs

    PCM Support

    Pion WebRTC now supports sending and receiving PCM.

    Renegotiation

    You can now Add/Remove tracks at anytime, and renegotiate! We have add a new minimal example called play-from-disk-renegotation that demonstrates this behavior. This example allows you to play a video back from disk multiple times, and you can stop the individual instances at any time!

    Add IVFReader

    We now have a Go implementation of an .ivf Demuxer. This allows users to easily playback files from disk. Pion also provides an IVFWriter, so you could easily save a file to disk and play it back later. Implemented by @justinokamoto

    VP9 Support

    You can now send and receive VP9. Implemented by @at-wat

    Next Release

    The next release will contain lots of bugfixes and other improvements, but the general goals for the next 6 months are.

    Better Stats

    Pion WebRTC is seeing lots of usage for load testing and measuring WebRTC servers. We are going to work on implement as many webrtc-stats as possible, after that we are going to explore building a framework on top of the PeerConnection API that makes load testing easier. We also want to make it easier to measure things in production, have an application that is easy to build deploy to production that can measure how your service is behaving will help a lot of users.

    Better Media

    Pion WebRTC lacks a in-tree JitterBuffer and Congestion Control. Users like ion right now have to implement it themselves. In the future Pion WebRTC will allow users to pass their own implementations (because they know their needs best), but provide some default implementations.

    Better Performance

    We are going to start measuring allocations, create real benchmarks and working on getting them better. We then need to add these benchmarks to CI and make sure they never regress.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.0(Jul 31, 2019)

    The Pion team is excited to announce the v2.1.0 release of Pion WebRTC. This release represents 3 months of feature development and testing across a variety of Pion projects. The headline features are:

    TURN Support

    Thanks to @enobufs Pion WebRTC now has full TURN support. This has been tested against multiple Open Source and hosted TURN providers.

    Stats

    @hugoArregui has added support for webrtc-stats. This initial implementation collects stats related to the PeerConnection, DataChannels, ICECandidates and ICECandidatePairs. The status and remaining work is being tracked in #610

    mDNS Host Candidates

    WebRTC has added mDNS candidates to help with privacy when using WebRTC, you can read the RFC here. We are able to parse and connect to these candidates. Currently we don't generate them, but in the future we will make this controllable by the user.

    vnet

    Pion WebRTC now implements a virtual network layer. You can read more about it here. This feature allows people to construct networks that only exist in software. This will allow users to simulate real world network conditions simulating NATs, packet loss, bandwidth and jitter without every actually sending a packet. Thanks to this feature written by @enobufs we have fixed multiple bugs in pion/turn and pion/ice already!

    Trickle ICE

    Trickle ICE is now available! This is controlled by the SettingEngine. We will make this the default in Pion v3 since it is a breaking change, and is not apparent to the user via an API change. Thank you @trivigy and @hugo for all your work on this.

    Source code(tar.gz)
    Source code(zip)
  • v1.2.0(Dec 23, 2018)

    This is the third public release of pion-WebRTC, thanks for trying it out!

    We hope you have as much fun using it and we did making it. Thank you so much to everyone that contributed, the code and bug reports of the community are what makes it all possible.


    This release adding the following features

    • Raw RTP Input You can now supply RTP packets directly. Instead of parsing and rebuilding packets you can just forward. This should improve performance for this use case, and will make code simpler. Implemented by Michael MacDonald

    • Allow adding Trickle-ICE candidates ICE candidates can now be added at any time, making pion-WebRTC compatible with WebRTC implementations that use trickle ICE like Chromium and FireFox. Implement by Michael MacDonald

    • Implement RTCP Reception The API now provides code to emit and handle RTCP packets, allowing you to build applications that interact and emit RTCP packets. Implemented by Woodrow Douglass

    • Transport refactor The internals of pion-WebRTC have been completely rewritten. This allows us to move subsystems to their own packages, cleaner code and fixed bugs along the way! Soon we should be able to provide ICE, SRTP, SCTP and more libraries for general use. We also now can explore alternative APIs like ORTC. Implemented by Michiel De Backker

    • Go native DTLS We are now 100% Go, removing our last C dependency (OpenSSL) We also now are able to provide a DTLS implementation to the greater community and are really excited about all the opportunities it opens up. Implemented by Michiel De Backker and Sean DuBois

    • Improve SRTP code and add auth tag checking Fixed a bug where wrong SRTP keys were used, in some cases video would fail to decode. Also expanded the SRTP code to do tag checking Implemented by Tobias Fridén

    • Add go-fuzz support to RTCP, and discovered crash in RTP code Implemented by Max Hawkins


    We ship with the following demos you can base your application off of.

    • data-channels Shows how to use DataChannels and send/receive data to your browser
    • gstreamer-receive Shows how to receive video and play or process it via GStreamer
    • gstreamer-send Shows how to generate video via GStreamer and send it to your browser
    • janus-gateway/streaming Shows how to use connect to a Janus streaming mountpoint and save to an ivf container
    • janus-gateway/video-room Shows how to use connect to a Janus video-room and publish video
    • pion-to-pion Shows to communicate between two Pion instance using DataChannels, no browser required!
    • save-to-disk Shows how to receive VP8 from your browser and save to an ivf container
    • sfu Shows how to broadcast a video to many peers, while only requiring the broadcaster to upload once

    To see what features are planned in the future, please see our roadmap

    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Oct 2, 2018)

    This is the second public release of pion-WebRTC, thanks for trying it out! Hopefully you have as much fun using it and we did making it

    This release adding the following features

    • Full ICE. pion-WebRTC is able to be controlling or controlled and can connect to itself.
    • DataChannels. pion-WebRTC can now send and receive messages via SCTP DataChannels.
    • RTCP. pion-WebRTC now is able to send and receive RTCP, making it a great building block for building things like an SFU.

    We also ship with the following demos you can base your application off of.

    • data-channels Shows how to use DataChannels and send/receive data to your browser
    • gstreamer-receive Shows how to receive video and play or process it via GStreamer
    • gstreamer-send Shows how to generate video via GStreamer and send it to your browser
    • janus-gateway Shows how to use connect to a Janus streaming mountpoint and save to an ivf container
    • pion-to-pion Shows to communicate between two Pion instance using DataChannels, no browser required!
    • save-to-disk Shows how to receive VP8 from your browser and save to an ivf container
    • sfu Shows how to broadcast a video to many peers, while only requiring the broadcaster to upload once

    To see what features are planned in the future, please see our roadmap

    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(Jul 4, 2018)

    This is the first public release of pion-WebRTC. Thank you for checking it out!

    pion-WebRTC is not finished, but ships with the following features

    • Send and receiving audio and video
    • Go Native SRTP
    • DTLS via OpenSSL (we still require Cgo just for this, but will be rewritten soon)
    • ICE-lite (requires that pion-WebRTC is run on a public IP, or communicates with in a LAN)

    We also ship with the following demos you can base your application off of.

    • gstreamer-send Shows how to generate video via GStreamer and send it to your browser
    • gstreamer-receive Shows how to receive video and play or process it via GStreamer
    • save-to-disk Shows how to receive VP8 from your browser and save to an ivf container

    To see what features are planned in the future, please see our roadmap

    Source code(tar.gz)
    Source code(zip)
Owner
Pion
The Open Source, Cross Platform Stack for Real-time Media and Data Communication.
Pion
Pure Go implementation of the WebRTC API

Pure Go implementation of the WebRTC API

Pion 7.5k Jul 23, 2021
null

chrome-webrtc-packet-log-parser Project status At this point the project is primerly intended to be used by checking it out and modifying main.go, how

Pro Emergotech Ltd. 22 Jun 7, 2021
A toy MMO example built using Ebiten and WebRTC DataChannels (UDP)

Ebiten WebRTC Toy MMO ⚠️ This is a piece of incomplete hobby work and not robust. Please read the "Why does this project exist?" section. What is this

Jae Bentvelzen 8 Jun 3, 2021
gRPC over WebRTC

gRPC over WebRTC Just a proof of concept, please be kind. How to Start all the things Client, create-react-app + grpc-web signaling + webrtc extension

Jean-Sebastien Mouret 227 Jul 10, 2021
Deskreen turns any device with a web browser into a secondary screen for your computer

Deskreen Website: https://deskreen.com ▶️ Deskreen Youtube channel (video tutorials, demos, use cases for Deskreen day to day usage) Deskreen turns an

Paul Pavlo Buidenkov 11.1k Jul 17, 2021
Playing with go, gobot & pion

Tello-WebRTC-FPV Lately there were a couple of articles about pion and it looked very cool, but I didn't know what I could do with it. I then remember

null 32 Jun 28, 2021
Group peer to peer video calls for everyone written in Go and TypeScript

Peer Calls v4 WebRTC peer to peer calls for everyone. See it live in action at peercalls.com. The server has been completely rewriten in Go and all th

Peer Calls 947 Jul 25, 2021
Distributed RTC System by pure Go and Flutter

ION is a distributed real-time communication system, the goal is to chat anydevice, anytime, anywhere! Distributed Real-time Communication System ION

Pion 3.1k Jul 22, 2021
A yet to be voice call application in terminal. with the power of go and webRTC (pion).

Kenny I'm just trying to make a cli operated voice call chat application using go with help of webRTC and PortAudio. It might stay a Work In Progress

Mohammad Fatemi 32 Jul 4, 2021
Scalable WebRTC Signaling Server with ayame-like protocol.

ayu ayu is WebRTC Signaling Server with ayame-like protocol. Scalable: ayu uses Redis to store room states, so it can be used on serverless platforms

castaneai 14 Jul 19, 2021
screen sharing for developers https://screego.net/

screego/server screen sharing for developers Huge thanks to sipgate for sponsoring this project! Intro In the past I've had some problems sharing my s

screego 3.4k Jul 25, 2021
Talk, easily.

Quik.do v0.1.0 talk, easily. Note: This project is heavily under development. IT IS NOT PRODUCTION READY YET. DO NOT USE IT. What Quik.do is a video c

Bora Tanrıkulu 93 Jul 19, 2021
A QUIC implementation in pure go

A QUIC implementation in pure Go quic-go is an implementation of the QUIC protocol in Go. It implements the IETF QUIC draft-29 and draft-32. Version c

Lucas Clemente 5.6k Jul 23, 2021
Fast RFC 5389 STUN implementation in go

STUN Package stun implements Session Traversal Utilities for NAT (STUN) [RFC5389] protocol and client with no external dependencies and zero allocatio

null 467 Jul 17, 2021