| The WebRTC part would indeed be convoluted. First, you would need to encrypt the RTP packets with DTLS. Then, you would need an SDP message generator, where you would include all sorts of info: * Codec and tunings of video and audio streams. * RTCP ports where you'll be listening from RTCP Receiver feedback, if any. * The TLS keys used for encryption. * Some fake ICE candidates that the other part can use to reach you. Then provide this as an SDP Offer to the WebRTC API of the other side (i.e. the RTCPeerConnection if we're talking about a web browser), and receive in response an SDP Answer. You should then be able to parse this Answer because the other participant might have rejected some of the parameters you gave it in the Offer (e.g. it could be ready only for audio and reject your video). Or just ignore the Answer and hope that you know the other party so well that they won't reject any of the parameters you provided in the Offer. Finally you would need to receive ICE candidates from the other party, and parse them in order to know where (what IP and port) to send your RTP packets (and RTCP Sender Reports, if any) |