Please observe the timestamp on the Channel-Bind requests.

These requests were done one after the other. No actual data was transferred while this "burst" was happening. Once all the channel-bind's were done.

I will investigate the source code, but I believe that while the channel-bind was still in progress, every data packet triggered a new channel bind request. I will add more information soon.

move webrtc-rs/rtp#11 to here

UDP*

I expect that * to lead a phrase like "Typically UDP, but can use TCP as well if needed", but in reality it just dangles.

hello
when i run TURN example it's works just once
turn args

--port 3478 --public-ip 192.168.1.250 --users user=pass

and tested with

https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

give me valid params just first time i click gather

*port-forwarding and NAT enabled in router and my public ip have DDNS

Originally posted by @Ali-Mirghasemi in #59

Cipher Suite, i.e., CipherSuiteTLSEcdheEcdsaWithAes128GcmSha256, CipherSuiteTLSEcdheEcdsaWithAes256CbcSha, uses Arc<Mutex<*>>. However, Atmoic should be used to improve the performance.

For BufWriter, if you uses

let mut writer = BufWriter::new(&mut buf);
or
let mut writer = BufWriter::<&mut Vec>::new(dst.as_mut());
BufWriter will append data to the Vec buffer.

If you uses

let mut writer = BufWriter::new(buf.as_mut_slice());
BufWriter will mutate the buffer data, but the drawback is that if buffer is not big enough, BufWriter won't increase the buffer size.

We need to find a way to handle misusing of byte slice case.

move webrtc-rs/sctp#1 to here

looking at the state cookie generation implementation, shouldn't it include HMAC generation and other things as mentioned here?

Here is the roadmap of WebRTC.rs project.

v0.1.0 (09/25/2021)

• SDP
• mDNS
• STUN
• TURN
• ICE
• DTLS
• RTP
• RTCP
• SRTP
• SCTP
• DataChannel API
• Media API
• PeerConnection API

v0.2.0 (10/09/2021)

• More features in Interceptor
• • NACK
• • RTCP SR/RR
• H.264/VP9 support
• #106

v0.3.0 (11/07/2021)

• #116
• #117
• #114
• #102

v0.3.1 (11/15/2021)

• #126

v0.4.0 (01/17/2022)

• #151
• webrtc-rs/interceptor#2

v0.5.0 (09/07/2022)

See changelog for updates https://github.com/webrtc-rs/webrtc/blob/master/webrtc/CHANGELOG.md#050

v0.5.1(09/19/2022)

See changelog for updates https://github.com/webrtc-rs/webrtc/blob/master/webrtc/CHANGELOG.md#051

v0.6.0 (11/15/2022)

See changelog for updates https://github.com/webrtc-rs/webrtc/blob/master/webrtc/CHANGELOG.md#v060

TBD

• #94
• #55
• #118
• • #17
• • #18
• • #20
• • #19
• • #112
• • #113
• #101
• #119
• #84
• • #136

long-term features

• #132
• DTLS 1.3: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/
• QUIC: https://datatracker.ietf.org/doc/html/rfc9000

Hi all!

Probably not the best place to ask but I also don’t know where else. I am in the process of writing a video muxer which reads RTP streams and outputs them via OpenGL. Given I am using pion as the WebRTC side of things (for now, but given my OpenGL app is rust based I am able to use the RTP package from this org) I am basing my approach on the. ion-avp builder https://github.com/pion/ion-avp/blob/master/pkg/builder.go

So my question really is, has anyone else done this? I’m currently up to the part where I’m implementing the build loop and I’m discovering how much work there will be to port everything (namely the Sampler) so I was curious maybe sombody else has also tried this? Just hate doubling up the effort if someone smarter than me has already done the work :))

cheers
Michael.

add benchmark code for SDP so that we can understand what's performance of SDP

Currently only NamedCurve::P256 is supported.

https://github.com/webrtc-rs/webrtc/blob/master/dtls/src/curve/named_curve.rs

From the source code

async fn send_to(&mut self, p: &[u8], addr: SocketAddr) -> Result<usize> {
    // ...
    let mut perm = if let Some(perm) = self.perm_map.find(&addr) {
        *perm
    } else {
        let perm = Permission::default();
        self.perm_map.insert(&addr, perm);
        perm
    };

    let mut result = Ok(());
    for _ in 0..MAX_RETRY_ATTEMPTS {
        result = self.create_perm(&mut perm, addr).await;
        if let Err(err) = &result {
            if !Error::ErrTryAgain.equal(err) {
                break;
            }
        }
    }

The perm variable is read from perm_map but never written back to it. So, every time send_to is called, it will get a Idle permission, which triggers a new CreatePermission on the create_perm function.

After the create_perm is called, the perm variable should be set back to perm_map.

Besides that, there is no Lifetime tracking. If we didn't receive any packet from a given address for more than 300 seconds, then the Permission for that given address should be removed from the perm_map. Because we must update the permission.

hi
is it possible to disable STUN response (sfrlx) for some users and force them to use relay?

https://github.com/pion/transport/tree/master/vnet

Pion implements the following cipher suites, but here only CipherSuiteTLSEcdheEcdsaWithAes128GcmSha256/CipherSuiteTLSPskWithAes128GcmSha256 and CipherSuiteTLSEcdheEcdsaWithAes256CbcSha are implemented.

// Supported Cipher Suites
const (
	// AES-128-CCM
	TLS_ECDHE_ECDSA_WITH_AES_128_CCM   CipherSuiteID = 0xc0ac //TODO
	TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 CipherSuiteID = 0xc0ae //TODO

	// AES-128-GCM-SHA256
	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 CipherSuiteID = 0xc02b //Done
	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   CipherSuiteID = 0xc02f //TODO

	// AES-256-CBC-SHA
	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA CipherSuiteID = 0xc00a //Done
	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA   CipherSuiteID = 0xc014 //TODO

	TLS_PSK_WITH_AES_128_CCM        CipherSuiteID = 0xc0a4 //TODO
	TLS_PSK_WITH_AES_128_CCM_8      CipherSuiteID = 0xc0a8 //TODO
	TLS_PSK_WITH_AES_128_GCM_SHA256 CipherSuiteID = 0x00a8 //Done
)

move trait KeyingMaterialExporter to util crate
impl KeyingMaterialExporter for dtls::state
use KeyingMaterialExporter in srtp::config

Hi, first of all, I am a Pion lover. It's great to see movement in the Rust world. Since this project is very recent, how serious is this project? I am planning long-term for some of our software components. Rust might be valuable for us but we need WebRTC support. So don't get my question offensive in any way. Just curious if this is something I could base our stack on in the future.

Cheers
Chris

cargo fmt --all -- --check

/usr/share/rust/.cargo/bin/cargo fmt --all -- --check
thread 'main' panicked at 'bad span: .: ', src/tools/rustfmt/src/source_map.rs:52:13 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'bad span: `.`: ', src/tools/rustfmt/src/source_map.rs:52:13

There are many unit tests in https://github.com/pion/rtp/blob/master/packet_test.go
TestRFC8285******

Add proper distinct error handling across all crates.

crc32fast should be replaced with crc crate, due to crc32fast issue found in sctp crate

I did a simple test with using turn crate where I communicated with a TURN server running Coturn software.

Most of the packets my turn client sent to the server were discarded. When I commented out the FINGERPRINT attribute on the source code, i.e. the STUN packets will not contain FINGERPRINT attribute anymore, then the issue is solved. I can do a full communication using the TURN server.

Right now, I still don't know why coturn did discard packets with the FINGERPRINT attribute. But removing this attribute fixes the problem.

as title

Currently, Vec<u8> is widely used in webrtc.rs stack. However, it is not efficient.

Idiomatic way should use bytes crate (https://docs.rs/bytes) for zero-copy network programming.

bytes is a more robust, and often more performant, way to play with bytes compared to Vec<u8>.

This issue depends on issue #17 - #20. With the help of benchmarks, we can measure what's the improvement of usage of bytes.

Implement Debug to all defined traits so as to easily log trait data

Change

struct ClientSettings {
    buffer_size: usize,
    rto: Duration,
    rto_rate: Duration,
    max_attempts: u32,
    closed: bool,
    //handler: Handler,
    collector: Option<Box<dyn Collector>>,
    c: Option<Arc<dyn Conn + Send + Sync>>,
}

to

struct ClientSettings {
    buffer_size: usize,
    rto: Duration,
    rto_rate: Duration,
    max_attempts: u32,
    closed: bool,
    //handler: Handler,
    collector: Option<Box<dyn Collector + Send>>,
    c: Option<Arc<dyn Conn + Send + Sync>>,
}

Otherwise, the stun client is !Send, and cannot be spawned as a task on a threadpool

The dependency nix on its version 0.8 does not compile on Android due to a bug in it. Updating it to 0.22 and making a few adjustments on the code makes the compilation ok again, but the final application does not linking due to missing getifaddrs on Android.

May I suggest we delegate listing interfaces to a third party crate? https://crates.io/crates/get_if_addrs/0.5.3

Otherwise, we have to compile the C code that implements getifaddrs:
https://github.com/maidsafe-archive/get_if_addrs/blob/master/get_if_addrs-sys/build.rs

Once the appropriate approach is decided. I will gladly open a Pull Request

DTLS uses x509-parse(https://docs.rs/x509-parser) and x509-parse uses ring (https://github.com/briansmith/ring).
It looks like ring doesn't work in target x86_64-pc-windows-gnu. However, it supports x86_64-pc-windows-msvc.

like https://golang.org/pkg/context/.

Existing rust crate candidates:
https://docs.rs/io-context/0.2.0/io_context/
https://docs.rs/ctx/0.2.0/ctx/

move webrtc-rs/sctp#2 to here

Hi I’m looking to try and help out with the migration from pion, very new to rust but not to programming (and I’ve been using pion)

would there be a best place to help?

Follows the following documents to improve APIs of webrtc-rs crates to make them more idiomatic rust:

Rust API Guidelines: https://rust-lang.github.io/api-guidelines/about.html
Rust Design Patterns: https://rust-unofficial.github.io/patterns/intro.html
Elegant Library APIs in Rust: https://deterministic.space/elegant-apis-in-rust.html