pion/webrtc
### [`v3.0.3`](https://togithub.com/pion/webrtc/compare/v3.0.2...v3.0.3)
[Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.2...v3.0.3)
### [`v3.0.2`](https://togithub.com/pion/webrtc/compare/v3.0.1...v3.0.2)
[Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.1...v3.0.2)
### [`v3.0.1`](https://togithub.com/pion/webrtc/compare/v3.0.0...v3.0.1)
[Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.0...v3.0.1)
### [`v3.0.0`](https://togithub.com/pion/webrtc/releases/v3.0.0)
[Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.16...v3.0.0)
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](https://togithub.com/pion/awesome-pion) or [example-webrtc-applications](https://togithub.com/pion/example-webrtc-applications) for what people are doing. We maintain a feature list and other helpful resources in our [README.md](https://togithub.com/pion/webrtc/blob/master/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](https://webrtcglossary.com/trickle-ice/)
- 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
```go
peerConnection, _ := webrtc.NewPeerConnection(webrtc.Configuration{})
offer, _ := peerConnection.CreateOffer()
peerConnection.SetLocalDescription(offer)
// Send `offer` to remote peer
websocket.Write(offer)
```
##### After
```go
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
```go
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](https://togithub.com/pion/webrtc/commit/bb3aa9717f912735dc09c46637965a3126a2ab2f)
##### 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](https://togithub.com/pion/webrtc/commit/abd6a35654756080699952b43edf7f21a6a8b8b8)
##### `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
```go
videoTrack, err := peerConnection.NewTrack(payloadType, randutil.NewMathRandomGenerator().Uint32(), "video", "pion")
```
Needs to become like one of the following
```go
videoTrack, err := webrtc.NewTrackLocalStaticSample(webrtc.RTPCodecCapability{MimeType: "video/vp8"}, "video", "pion")
```
```go
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](https://togithub.com/pion/mediadevices/blob/master/examples/webrtc/main.go) 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
```go
m.RegisterCodec(webrtc.NewRTPOpusCodec(webrtc.DefaultPayloadTypeOpus, 48000))
m.RegisterCodec(webrtc.NewRTPVP8Codec(webrtc.DefaultPayloadTypeVP8, 90000))
```
After
```go
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](https://togithub.com/pion/webrtc/commit/7edfb701e09e89258d4b3235cded99befc8058fd)
#### 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.
```go
peerConn, _ := NewPeerConnection(Configuration{})
// PeerConnection goes to ICEConnectionStateFailed
offer, _ := peerConn.CreateOffer(&OfferOptions{ICERestart: true})
```
This was implemented in [f29414](https://togithub.com/pion/webrtc/commit/f2941469f47c93124062dddd5c8805392c2506c9)
##### 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](https://togithub.com/pion/webrtc/tree/master/examples/ice-tcp)
This was implemented in [2236dd](https://togithub.com/pion/webrtc/commit/2236ddeafd18b1fc4553c0dba8884d4ecd7ff9c9)
##### OnNegotationNeeded
[onnegotationneeded](https://w3c.github.io/webrtc-pc/#event-negotiation) 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](https://togithub.com/pion/webrtc/commit/c5819d521f4de602a0501ba873d436fb1271108)
##### Simulcast
You can now send Simulcast feeds to Pion WebRTC! It uses MID/RID identification as defined in [ietf-mmusic-sdp-simulcast](https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-14). An example has been provided at [examples/simulcast](https://togithub.com/pion/webrtc/tree/master/examples/simulcast).
This was implemented in [6ee528](https://togithub.com/pion/webrtc/commit/6ee528d349a5642fd43e90fec67a287cf31c01a9)
##### SRTP AEAD_AES_128_GCM
pion/srtp added support for the SRTP Cipher [AEAD_AES_128_GCM](https://tools.ietf.org/html/rfc7714). 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](https://togithub.com/pion/srtp/commit/f871f43141302fefa7fcdde700674881f0194670)
##### Interceptor
v3.0.0 introduces a new Pion specific concept known as a [interceptor](https://togithub.com/pion/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](https://togithub.com/pion/interceptor/blob/master/README.md) in pion/interceptor for the most up to date information.
- [Sender and Receiver Reports](https://tools.ietf.org/html/rfc3550#section-6.4)
- Bandwidth Estimation from Receiver Reports
- [Transport Wide Congestion Control Feedback](https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01)
- [NADA](https://tools.ietf.org/html/rfc8698)
- [Google Congestion Control](https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02)
- JitterBuffer, re-order packets and wait for arrival
- [FlexFec](https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-20)
- [webrtc-stats](https://www.w3.org/TR/webrtc-stats/) compliant statistics generation
#### WebRTC for the Curious
The Pion developers started a free book on how WebRTC actually works. It is available at 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 [#1615](https://togithub.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
### [`v3.0.0-beta.16`](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.15...v3.0.0-beta.16)
[Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.15...v3.0.0-beta.16)
### [`v3.0.0-beta.15`](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.14...v3.0.0-beta.15)
[Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.14...v3.0.0-beta.15)
### [`v3.0.0-beta.14`](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.13...v3.0.0-beta.14)
[Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.13...v3.0.0-beta.14)
### [`v3.0.0-beta.13`](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.12...v3.0.0-beta.13)
[Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.12...v3.0.0-beta.13)
### [`v3.0.0-beta.12`](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.11...v3.0.0-beta.12)
[Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.11...v3.0.0-beta.12)
### [`v3.0.0-beta.11`](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.10...v3.0.0-beta.11)
[Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.10...v3.0.0-beta.11)
Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
:no_bell: 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 contains the following updates:
v3.0.0-beta.10->v3.0.3Release Notes
pion/webrtc
### [`v3.0.3`](https://togithub.com/pion/webrtc/compare/v3.0.2...v3.0.3) [Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.2...v3.0.3) ### [`v3.0.2`](https://togithub.com/pion/webrtc/compare/v3.0.1...v3.0.2) [Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.1...v3.0.2) ### [`v3.0.1`](https://togithub.com/pion/webrtc/compare/v3.0.0...v3.0.1) [Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.0...v3.0.1) ### [`v3.0.0`](https://togithub.com/pion/webrtc/releases/v3.0.0) [Compare Source](https://togithub.com/pion/webrtc/compare/v3.0.0-beta.16...v3.0.0) 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](https://togithub.com/pion/awesome-pion) or [example-webrtc-applications](https://togithub.com/pion/example-webrtc-applications) for what people are doing. We maintain a feature list and other helpful resources in our [README.md](https://togithub.com/pion/webrtc/blob/master/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](https://webrtcglossary.com/trickle-ice/) - 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 ```go peerConnection, _ := webrtc.NewPeerConnection(webrtc.Configuration{}) offer, _ := peerConnection.CreateOffer() peerConnection.SetLocalDescription(offer) // Send `offer` to remote peer websocket.Write(offer) ``` ##### After ```go 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 ```go 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](https://togithub.com/pion/webrtc/commit/bb3aa9717f912735dc09c46637965a3126a2ab2f) ##### 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](https://togithub.com/pion/webrtc/commit/abd6a35654756080699952b43edf7f21a6a8b8b8) ##### `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 ```go videoTrack, err := peerConnection.NewTrack(payloadType, randutil.NewMathRandomGenerator().Uint32(), "video", "pion") ``` Needs to become like one of the following ```go videoTrack, err := webrtc.NewTrackLocalStaticSample(webrtc.RTPCodecCapability{MimeType: "video/vp8"}, "video", "pion") ``` ```go 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](https://togithub.com/pion/mediadevices/blob/master/examples/webrtc/main.go) 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 ```go m.RegisterCodec(webrtc.NewRTPOpusCodec(webrtc.DefaultPayloadTypeOpus, 48000)) m.RegisterCodec(webrtc.NewRTPVP8Codec(webrtc.DefaultPayloadTypeVP8, 90000)) ``` After ```go 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](https://togithub.com/pion/webrtc/commit/7edfb701e09e89258d4b3235cded99befc8058fd) #### 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. ```go peerConn, _ := NewPeerConnection(Configuration{}) // PeerConnection goes to ICEConnectionStateFailed offer, _ := peerConn.CreateOffer(&OfferOptions{ICERestart: true}) ``` This was implemented in [f29414](https://togithub.com/pion/webrtc/commit/f2941469f47c93124062dddd5c8805392c2506c9) ##### 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](https://togithub.com/pion/webrtc/tree/master/examples/ice-tcp) This was implemented in [2236dd](https://togithub.com/pion/webrtc/commit/2236ddeafd18b1fc4553c0dba8884d4ecd7ff9c9) ##### OnNegotationNeeded [onnegotationneeded](https://w3c.github.io/webrtc-pc/#event-negotiation) 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](https://togithub.com/pion/webrtc/commit/c5819d521f4de602a0501ba873d436fb1271108) ##### Simulcast You can now send Simulcast feeds to Pion WebRTC! It uses MID/RID identification as defined in [ietf-mmusic-sdp-simulcast](https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-14). An example has been provided at [examples/simulcast](https://togithub.com/pion/webrtc/tree/master/examples/simulcast). This was implemented in [6ee528](https://togithub.com/pion/webrtc/commit/6ee528d349a5642fd43e90fec67a287cf31c01a9) ##### SRTP AEAD_AES_128_GCM pion/srtp added support for the SRTP Cipher [AEAD_AES_128_GCM](https://tools.ietf.org/html/rfc7714). 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](https://togithub.com/pion/srtp/commit/f871f43141302fefa7fcdde700674881f0194670) ##### Interceptor v3.0.0 introduces a new Pion specific concept known as a [interceptor](https://togithub.com/pion/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](https://togithub.com/pion/interceptor/blob/master/README.md) in pion/interceptor for the most up to date information. - [Sender and Receiver Reports](https://tools.ietf.org/html/rfc3550#section-6.4) - Bandwidth Estimation from Receiver Reports - [Transport Wide Congestion Control Feedback](https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01) - [NADA](https://tools.ietf.org/html/rfc8698) - [Google Congestion Control](https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02) - JitterBuffer, re-order packets and wait for arrival - [FlexFec](https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-20) - [webrtc-stats](https://www.w3.org/TR/webrtc-stats/) compliant statistics generation #### WebRTC for the Curious The Pion developers started a free book on how WebRTC actually works. It is available atRenovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by WhiteSource Renovate. View repository job log here.