As explained in the imquic public API, imquic_create_server and imquic_create_client are the methods you can use to create a new, generic, QUIC server or client, with the related callbacks to be notified about what happens on new or existing connections. That API assumes you'll be entirely responsible of the application level protocol details, though.

Out of the box, imquic provides native support for a few specific protocols, meaning it can deal with the lower level details of the application level protocol, while exposing a simpler and higher level API to use the protocol features programmatically. RTP Over QUIC is one of those protocols.

When you want to use the native RoQ features of imquic, you must not use the generic functions and callbacks, but will need to use the RoQ variants defined in this page instead. Specifically, to create a RoQ server you won't use imquic_create_server, but will use imquic_create_roq_server instead; likewise, a imquic_create_roq_client variant exists for creating RoQ clients too.

The same applies to callbacks for incoming events. Attempting to use the generic callback setters on a RoQ endpoint will do nothing, and show an error on the logs: you'll need to use the RoQ specific callbacks. This means that to be notified about a new RoQ connection (whether you're a client or a server), you'll use imquic_set_new_roq_connection_cb, while to be notified about connections being closed you'll need to use imquic_set_roq_connection_gone_cb instead. The same considerations made on reference-counting connections in generic callbacks applies here too, since the same structs are used for endpoints and connections: it's just the internals that are different. Starting the endpoint after configuring the callbacks, instead, works exactly the same way as in the generic API, meaning you'll be able to use imquic_start_endpoint.

Being notified about incoming RTP packets is much easier as well, as rather than having to worry about handling incoming STREAM or DATAGRAM data, and potentially demultiplex/reconstruct RTP packets across multiple STREAM chunks, using imquic_set_rtp_incoming_cb you can be notified about full RTP packets instead, independently of how they were multiplexed by the sender. The callback will also notify you about the flow ID associated with the packet, making it much easier to just handle the application level specifics (e.g., mapping incoming packets to a specific session).

Sending RTP packets follows the same simplification, since all you need to do is use imquic_roq_send_rtp and specify which multiplexing mode you want to use for encapsulating the RTP packet on top of QUIC. Depending on whether DATAGRAM or STREAM are used, the RoQ stack will handle that internally for you: when using STREAM , it's up to you to tell the stack when to close the stream, thus allowing you to choose how many packets to send over the same stream (e.g., all packets on the same stream, one stream per packet, or anything in between).