Detalles del código fuente webrtc de nackamp;rtx
m=video 9 RTP/AVPF 96 97 98 99 100 101127 122 108 109 123
a=rtpmap：96 H264/900000
a=rtcp-fb：96 goog-remb
a=rtcp-fb：96 transporte-cc
a=rtcp-fb：96 ccm fir
a=rtcp-fb：96 nack
a=rtcp-fb：96 nack pli
a=fmtp：96 nivel-asimetría-permitido=1; perfil-nivel-id=42001f
a=rtpmap：97 rtx/90000
a=fmtp：97 apt=96
La negociación de vídeo es h264 (válido Tipo de carga útil = 96)
De sdp podemos obtener:
1) perfil-nivel-id=42001f
?Perfil: 66 (hexadecimal: 42 )
?Nivel: 3.1 (Hex: 1f) Convertir a decimal y dividir por 10
2) packageization-mode=1
?Representación El marco I dividirse en múltiples paquetes de datos rtp y enviarse, como 264. Los 5 bits inferiores del primer byte (0x7C) de rtppayload son (11100), que es 28 en decimal, lo que indica que el nalutype es FU-A, es decir, Múltiples paquetes de datos.
3)RTP/AVPF
? La F en AVPF indica compatibilidad con la protección de la capa de transporte RTCP y la S indica protección de seguridad (SRTP)
4) a = fmtp: 97 apt=96
? Indica que los paquetes de retransmisión de paquetes rtp de tipo 96 están protegidos por paquetes rtx de tipo de carga útil 97. El número de secuencia en el encabezado rtp del paquete rtx es diferente del número de secuencia en el encabezado rtp, pero la marca de tiempo es la misma.
?Los primeros dos bytes de la carga útil del paquete Rtx son el número de secuencia rtp del paquete rtp retransmitido original
2. Proyecto de modificación del proyecto webrtcpeerconnection_client
1) Eliminar srtp
a) La interfaz setOption de peerconnectionFactory deshabilita las opciones de cifrado
?webrtc::PeerConnectionFactoryInterface::Optionsoptions;
?options.disable_encryption=true;
?peer_connection_factory_-gt;SetOptions(opciones);
? b) peer_connection_factory_-gt;La interfaz CreatePeerConnection cierra las opciones dtls srtp
?webrtc::PeerConnectionInterface::RTCConfigurationconfig ;
?config.sdp_semantics = webrtc::SdpSemantics::kUnifiedPlan;
?config.enable_dtls_srtp= false
2) Eliminar FEC;
Agregar parámetro FEC deshabilitado
webrtc::field_trial::InitFieldTrialsFromString(FLAG_force_fieldtrials)
FLAG_force_fieldtrials = WebRTC- DisableUlpFecExperiment/Enabled/
3 .análisis de captura de paquetes de Wireshark
1) rtx_rtp.
pcapng es 20 capturas de paquetes p2p webrtc bajo pérdida aleatoria de paquetes
Condiciones de filtro: (ip.src==10.25.8.112 y (rtp.p_type==96 o rtp.p_type==97)) o (rtcp and ip.dst==10.25.8.112 andrtcp.rtpfb.fmt == 1)
rtcp.rtpfb.fmt == 1 significa paquete nack
2) nack Estructura de la información
81 CD 00 03 A5 1F D8 4A 52 5E 1A 85 34 0F 00 00
a) encabezado rtcp 4 bytes (81 CD 00 03)
?100 00001 (81) El primer byte
?Indica que los 2 bits altos (10) de vesion deben ser 2
?1 bit indica si rtcp está relleno (relleno), 0 significa sin relleno, 1 significa que el valor del último byte de la carga útil de rtcp es paddingsize
? 5 bits significa que el valor del tipo de mensaje de retroalimentación (fmt) de rtcp es 1
11001101 (cd) El segundo byte
? El segundo byte indica el tipo de paquete, el valor es 205
? El tipo de paquete (205) y fmt (1) cambian esto. El mensaje se identifica como nack. mensaje
?(00 03) El tercer y cuarto bytes
?El tercer byte indica la longitud de rtcp (excluyendo 4 de los bytes del encabezado rtcp), la longitud de la información nack es constante 16 (3*4 4)
b) Carga útil Nack (a5 1f d8 4a 52 5e 1a 8534 0f 00 00)
?4 bytes del remitente SSRC (a5 1f d8 4a) , rtp ssrc de la pista que envía RTCP, en caso afirmativo (solo recepción), el valor es 0
?4 bytes de fuente de medios SSRC (52 5e 1a 85), RTCP SSRC correspondiente al paquete de datos que solicita la retransmisión
? pid nack de retroalimentación de transmisión RTCP de 2 bytes (34 0f), determine el número de secuencia RTCP inicial (13327)
?Máscara de bits nack de retroalimentación de transmisión RTCP de 2 bytes (0000), pérdida de paquetes de 16 grupos de paquetes a partir del pid inicial, este valor es una máscara convertida a binaria. El valor es una máscara convertida a binario, con un bit de 1 que indica pérdida de paquete y 00 00 que indica que solo se perdió el paquete correspondiente a pid.
3) paquete de datos de retransmisión rtx
Principio de Rtx: el paquete de datos retransmitido se encapsula en un paquete de datos RTX y se envía. El SSRC del paquete de datos RTX es diferente del RTP original. y el rtpseq también es diferente, pero la marca de tiempo es la misma que la del paquete perdido.
Ventajas de Rtx: los paquetes de retransmisión rtp no se incluyen en la operación de estimación del ancho de banda. Es más conveniente usar rtx. La tasa de pérdida de paquetes contada sin usar rtx a veces será negativa.
?Rtxpayload: Los primeros dos bytes representan la secuencia rtp del paquete perdido, por lo que el paquete rtx es 2 bytes más que el paquete rtp perdido
4) El remitente rtp en webrtc maneja el mensaje RTCP NACK El proceso es como "Procesamiento de mensajes RTCPNACK por sender.pdf"
5) El proceso de webrtc para encontrar paquetes de datos perdidos en el receptor rtp y enviar solicitudes nack se puede encontrar en "El proceso de envío de mensajes nack del receptor rtp .pdf" "
Documentación y paquetes capturados, dejar correo electrónico si lo desea.