Razones para Adoptar el Estándar GB28181

GB28181 es un estándar universal imprescindible para integrarse en plataformas de video guberanmentales, como las de seguridad pública. Su uso asegura compatibilidad entre sistemas y simplifica el desarrollo al evitar modificaciones constantes.

Flujo de Código según GB28181

Los datos de video deben encapsularse en formato PS (Program Stream). Para un análisis técnico profundo, se puedan consultar recursos especializados en protocolos de transmisión multimedia.

Codificación de Dispositivos

Cada dispositivo se identifica con un código de 20 dígitos, donde los dígitos en posiciones 11 a 13 definen el tipo, como cámaras (código 132) o servidores. Un código mal formado impedirá la comunicación SIP. Ejemplo de IDs de dispositivos:

<Device Id="11010000001310000001" Name="Sensor Norte" Status="ON"/>
<Device Id="11010000001310000002" Name="Sensor Sur" Status="ON"/>
<Device Id="11010000002000000001" Name="Servidor Central" Status="ON"/>
<Device Id="11010000004000000001" Name="Terminal Usuario" Status="ON"/>

Protocolo SIP para Comunicación

GB28181 utiliza SIP (Session Initiation Protocol) para la señalización. Cada dispositivo recibe un ID único que facilita la gestión y el enrutamiento. La extensibilidad de SIP y bibliotecas como osip2 o exosip2 agilizan la integración.

Configuración de Cámaras

Las cámaras deben habilitar el soporte para GB28181 a través de su interfaz de administración. La configuración incluye parámetros SIP específicos, como el servidor de registro y credenciales.

Transmisión de Flujos de Video

SIP facilita la transmisión P2P al negociar direcciones públicas durante el establecimiento de sesión. Esto minimiza la intervención del servidor una vez establecida la conexión, reduciendo latencia y pérdidas de paquetes.

Proceso de Integración

Existen dos enfoques principales: integración como dispositivo subordinado, donde la cámara se registra activamente, o como servidor de cascada, que actúa como intermediario. El modo cascada permite gestionar listas de dispositivos y enrutar solicitudes de múltiples usuarios.

Intercambio SIP: Ejemplo Técnico

Consideremos un servidor con IP 10.0.0.1 e ID 11010000002000000001, y un cliente con IP 10.0.0.2 e ID 11010000004000000001. El flujo de registro y solicitud de video es ilustrativo:

REGISTER sip:11010000002000000001@10.0.0.1 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK838495
From: <sip:11010000004000000001@1101000000>;tag=54321
To: <sip:11010000004000000001@1101000000>
Call-ID: f7c23a98e12345@10.0.0.2
CSeq: 1 REGISTER
Contact: <sip:11010000004000000001@10.0.0.2:5060>
Max-Forwards: 70
Expires: 3600
Content-Length: 0

El servidor responde con un desafío 401 Unauthorized, y el cliente reenvía la solicitud con credenciales Digest. Tras el registro exitoso, el cliente inicia una sesión INVITE para solicitar flujo de video, especificando parámetros SDP para RTP/PS.

INVITE sip:11010000002000000001@10.0.0.1 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bK456789
From: <sip:11010000004000000001@1101000000>;tag=67890
To: <sip:11010000001310000001@1101000000>
Call-ID: 3a8f2e1c9d4567@10.0.0.2
CSeq: 20 INVITE
Contact: <sip:11010000004000000001@10.0.0.2:5060>
Content-Type: APPLICATION/SDP
Content-Length: 195

v=0
o=11010000004000000001 0 0 IN IP4 10.0.0.2
s=Play
c=IN IP4 10.0.0.2
t=0 0
m=video 5004 RTP/AVP 96
a=rtpmap:96 PS/90000
a=recvonly

El servidor confirma con 200 OK y proporciona su SDP, estableciendo un canal RTP directo para la transmisión de video. Los mensajes subsequentes, como MESSAGE para keepalive, mantienen la sesión activa.

La transmisión de video fluye directamente entre la cámara y el cliente tras la negociación SIP, optimizando recursos y ancho de banda.