2 unstable releases

0.2.1 Jun 19, 2022
0.0.1 May 14, 2022

#3 in #voip

Download history 458/week @ 2023-12-15 270/week @ 2023-12-22 312/week @ 2023-12-29 1003/week @ 2024-01-05 421/week @ 2024-01-12 764/week @ 2024-01-19 383/week @ 2024-01-26 309/week @ 2024-02-02 312/week @ 2024-02-09 288/week @ 2024-02-16 296/week @ 2024-02-23 200/week @ 2024-03-01 167/week @ 2024-03-08 131/week @ 2024-03-15 96/week @ 2024-03-22 105/week @ 2024-03-29

516 downloads per month
Used in 2 crates (via atm0s-media-server-transp…)

Custom license

170KB
4.5K SLoC

sdp-rs

Crates.io Version Released API docs License: MIT Minimum rustc version

A common general purpose library for SDP. It can parse and generate all SDP structures. Supports both RFC8866 and RFC4566.

Like rsip, this crate is a general purpose library for common types found when working with the SDP protocol. You will find high level types like the SessionDescription, MediaDescription and Time but you will also find line-level types like Connection or even types found inside a line, like Bwtype etc.

sdp-rs is capable of parsing messages from &str or String using nom parser and can also generate SDP messages using the main SessionDescription struct. Each type (high level type, line type or sub-line type) can be parsed or be displayed as it would, so you can work with part of an SDP message, if that's useful for you.

If you need parsing raw bytes (&[u8]) ping us. It is possible but we avoided doing that in the first place because a) it requires tons of traits/generics which will increase complexity and compile times b) SDP specification highly recommends that the input is UTF-8 c) performance of converting the bytes to UTF-8 should be negligible.

Features

  • This thing is fast, uses nom for basic message parsing.
  • Strong (new)types in most cases. Whenever for a type there is a strict specification, we opt for a strict (newtype) definition.
  • Very simple code structure make it super easy to extend and add new SDP lines and attributes As long as you can do nom stuff, it's straightforward. If you find dealing with nom difficult, you can always open an issue for the desired (missing) type. The goal is to add as many typed SDP attributes as possible.

Architecture

Each type in sdp-rs has a related tokenizer. This is not enforced by the type system yet, however very soon this will be the case. In brief, for every sdp-rs type we have:

  • Tokenizing: in the lowest level we have the Tokenizer which is capable of tokenizing the input. All common tokenizers accept the &str input. You shouldn't have to work directly with the tokenizers, these are being used indirectly in the parsing level.
  • Parsing: once the input has been tokenized into tokens, then there are TryFrom impls from the relevant type tokenizer to the actual type. This is the parsing step where tokens (in the form of &str) are transformed to integers, strings or sdp-rs types.
  • each sdp-rs type implements the Display trait and hence has a representation.

Dependencies

~2.5MB
~39K SLoC