I. Introduction
In this blog, we introduced the mediasoup-demo startup process and signaling interaction . Key signaling includes getRouterRtpCapabilites, join, createWebRtcTransport, connectWebRtcTransport, produce. This article will introduce the process of createWebRtcTransport and connectRtcTransport.
2. createWebRtcTransport
The signaling layer of mediasoup-demo processes the request parameters after receiving the createWebRtcTransport message and passes them as webRtcTransportOptions to the mediasoup C++ layer to create a transport. The request parameters include { forceTcp, producing, consuming, sctpCapabilities }.
Mediasoup Router creates RTC::WebRtcTransport object after receiving ROUTER_CREATE_WEBRTC_TRANSPORT request.
The processing flow of the WebRtcTransport constructor is as follows. First, obtain the enableUdp, enableTcp, preferUdp, and preferTcp parameter configurations. If enableUdp=true, the returned candidate address list includes UDP type (ip, port). If enableTcp=true, the returned candidate address The list contains (ip, port) of TCP type, preferUdp=true indicates that UDP is preferred, and preferTcp=true indicates that TCP is preferred, and the preference is reflected in the priority of candidate addresses.
If enableUdp and enableTcp are true at the same time, it means that the candidate lists of the two protocol types need to be returned, so the size of iceCandidates is set to twice the size of listenIps, and each iceCandidates corresponds to a UdpSocket or TcpSocket. The bottom layer of UdpSocket is the uv_udp_t object of libuv, which will call back the OnUdpSocketPacketReceived of WebRtcTransport after receiving the UDP packet data, and the bottom layer of TcpSocket is the uv_tcp_t object of libuv.
The priority calculation rules for candidates are:
icePriority = 2^24 * IceTypePreference + 2^8 * localPreference + 2^0 * (256 - IceComponent).
IceTypePreference is a fixed value of 64, and IceComponent is a fixed value of 1, indicating that icePriority is positively correlated with localPreference,
localPreference = IceCandidateDefaultLocalPriority - iceLocalPreferenceDecrement , .
IceCandidateDefaultLocalPriority is a fixed value of 10000, and iceLocalPreferenceDecrement will increase by 100 each time an address list is calculated, that is, the priority of the lower address in the address list is lower than that of the front address, and if the candidate of the corresponding type of preferUdp or preferTcp is set Or localPreference will add 1000.
The WebRtcTransport constructor finally creates the ICE Server and DTLS Transport objects.
ICE is called Interactive Connectivity Establishment (Interactive Connectivity Establishment). There are two types of ICE, one is full ICE, in this way both sides of the communication need to check the connectivity, the other is lite ICE, in this way the lite ICE side only needs to passively respond to the response message, that is, the lite ICE side There is no need to actively check the connectivity, as long as the full end completes the connectivity check, ICE Server corresponds to the implementation of lite ICE.
DTLS is a secure transport protocol at the UDP layer (similar to TLS), used to exchange keys for encryption and decryption of SRTP. When mediasoup starts, it will read the configured certificate file, and then generate different hash values (fingerprints) for the certificates. When verifying the validity of the certificates, the fingerprints can be compared. If the fingerprints are equal, it means that the issued certificate has not been modified.
After the transport is created, the signaling layer will listen to the sctpstatechange, dtlsstatechange, trace events sent by the C++ layer and deal with them accordingly.
createWebRtcTransport finally returns { id, iceParameters, iceCandidates, dtlsParameters, sctpParameters }.
| field | meaning |
| id | transport channel id |
| iceParameters | ICE type, ICE username, password |
| iceCandidates | ICE candidate information, including ip, port, protocol type, priority and other information |
| dtlsParameters | Certificate fingerprint information for DTLS handshake |
| sctpParameters | SCTP configuration information |
After the client receives the return result of createWebRtcTransport, it will start the media connectivity check, that is, send a STUN packet binding request to the address in the ICE candidates list, and mediasoup will respond with a binding response after receiving it. The content of the captured packet is as follows.
The header of the STUN message is as follows, Message Type indicates the message type (including Message Method and Message Class), Message Length indicates the length of the STUN message, excluding the 20-byte header, the Magic Cookie value is fixed at 0x2112A442, and the Transaction Id is the transaction ID , the tag ID number used for requests and responses. RFC3489 defines a 128-bit transaction ID, and RFC5389 divides a 128-bit transaction ID into a 32-bit Magic Cookie and a 96-bit Transaction Id, so the STUN protocol of RFC3489 or RFC5389 can be distinguished according to the Magic Cookie value.
The STUN packet header is followed by 0 or more attributes, and each attribute is coded in TLV format.
| Type | Attributes | meaning |
| 0x0001 | MAPPED-ADDRESS | Get the address of the client after mapping |
| 0x0006 | USERNAME | notification username |
| 0x0007 | PASSWORD | password for security authentication |
| 0x0008 | MESSAGE-INTEGRITY | Message integrity, including a SHA-1 hash value |
| 0x0009 | ERROR-CODE | error code type |
| 0x000A | UNKNOWN-ATTRIBUTES | unknown attribute |
| 0x0020 | XOR-MAPPED-ADDRESS |
XOR mapped address |
| 0x0024 | PRIORITY |
Candidate priority |
| 0x0025 | USE-CANDIDATE | nominate the candidate |
| 0x8028 | FINGERPRINT | Check the CRC value of the message |
| 0x8029 | ICE-CONTROLLED | Used to distinguish ICE roles, answer Party B is a controlled role |
| 0x802A | ICE-CONTROLLING | Used to distinguish ICE roles, the offer party is the controlling role |
三. connectWebRtcTransport
The request parameters of connectWebRtcTransport are transportId and dtlsParameters.
After mediasoup C++ receives the TRANSPORT_CONNECT message request, it will turn to the corresponding transport for processing. For the processing of WebRtcTransport, it needs to determine the DTLS role selected by the peer and enable DTLS interaction.
The DTLS interaction process is shown below. Please refer to this article for the meaning of each step of the DTLS process .
After executing the DtlsTransport Run function, the DTLS state enters CONNECTING. For the role of Client, call openssl SSL_set_connect_state, SSL_do_handshake, and for the role of Server, call openssl SSL_set_accept_state, SSL_do_handshake.
After DTLS negotiation is completed, calculate the key used by SRTP, notify WebRtcTransport->OnDtlsTransportConnected, and establish srtpSendSession after WebRtcTransport receives it, and finally notify mediasoup-demo signaling layer dtlsstatechange (connected).
